You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Sergei Morozov (Jira)" <ji...@apache.org> on 2025/08/20 00:13:00 UTC
[jira] [Updated] (FLINK-38218) MySQL CDC source may ignore newly added tables while reading the binlog (scenario 1)
[ https://issues.apache.org/jira/browse/FLINK-38218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergei Morozov updated FLINK-38218:
-----------------------------------
Summary: MySQL CDC source may ignore newly added tables while reading the binlog (scenario 1) (was: MySQL CDC source may ignore newly added tables while reading the binlog)
> MySQL CDC source may ignore newly added tables while reading the binlog (scenario 1)
> ------------------------------------------------------------------------------------
>
> Key: FLINK-38218
> URL: https://issues.apache.org/jira/browse/FLINK-38218
> Project: Flink
> Issue Type: Bug
> Components: Flink CDC
> Affects Versions: cdc-3.2.1
> Reporter: Sergei Morozov
> Priority: Major
> Labels: pull-request-available
>
>
> {*}Steps to reproduce{*}:
> # Prepare tables {{{}A{}}}, {{B}} and {{C}} to be captured by the source. The number of rows in {{B}} and {{C}} is irrelevant, table {{A}} needs to have enough rows for its snapshot to take a couple of minutes (100 rows should be enough given the configuration below).
> # Make sure the source has the following configuration parameters:
> ## {{{}chunk-meta.group.size: 2{}}}. This a small enough number to make the binlog split metadata transmitted in groups. {{1}} may work too but I didn't test with it.
> ## {{{}scan.snapshot.fetch.size: 2{}}}. This will guarantee that the snapshot of table A will take long enough (2 is the minimum allowed value).
> # Include tables {{B}} and {{C}} into the source's configuration.
> # Start the job and wait until it transitions to the binlog phase.
> # Stop the job.
> # Include table {{A}} into the configuration.
> # Start the job and wait until the source reader starts reporting finished offsets back to the enumerator.
> # Stop the job before the snapshot is completed.
> # Restart the job.
> # Wait until the snapshot of table A is finished and the source transitions to the binlog phase.
>
> {*}Expected behavior{*}: changes in table {{A}} are read from the binlog.
> {*}Actual behavior{*}: changes in table A in the binlog are ignored.
> h3. What's happening internally
>
> {*}Note{*}: for readability, I will use a simplified format for snapshot split IDs (instead of {{{}A:0{}}}, I will use just {{{}A{}}}).
> # The source reader snapshots tables {{B}} and {{C}} and reports their finished snapshot split infos to the enumerator.
> # Enumerator creates the binlog split with infos {{B}} and {{C}} and assigns it to the reader.
> # The job stops, gets table {{A}} included into the configuration and restarts.
> # The enumerator assigns split {{A}} and puts it into {{assignedSplits}} so the order of its keys becomes {{{}B{}}}, {{{}C{}}}, {{{}A{}}}.
> # The source reader snapshots {{A}} and reports its finished snapshot split info(s) to the enumerator.
> # If at this point the connection wasn't stopped and restarted, there wouldn't be an issue. But the connection gets stopped and restarted.
> # {{MySqlSnapshotSplitAssigner}} constructor sorts {{assignedSplits}} so the order of its keys becomes {{{}A{}}}, {{{}B{}}}, {{{}C{}}}.
> # The source reader knows that it has 2 split infos ({{{}B{}}} and {{{}C{}}}) but the new total number is 3, so it requests split meta group 1.
> # It receives the group with the following elements: {{{}C{}}}.
> # It calculates {{existedSplitsOfLastGroup}} (which is an empty set).
> # It doesn't deduplicate {{C}} and appends it to the finished split infos.
> # As a result, finished split infos look like B, C, C. The transmission is over, but the info for table A is lost.
> # Subsequently, for all changes from table {{{}A{}}}, {{BinlogSplitReader#shouldEmit()}} returns {{false}} because there's no finished snapshot split info for this table.
>
> Note that other connectors that use {{SnapshotSplitAssigner}} from the {{flink-cdc-base}} package may be prone to this issue as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)