ddl_puller.go(ticdc): fix DDLs are ignored when schema versions are out of order (#11733) #11758
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated cherry-pick of #11733
What problem does this PR solve?
Issue Number: close #11714
What is changed and how it works?
Description:
This pull request addresses a bug in TiCDC where a DDL job could be inadvertently dropped if a subsequent DDL job with a higher
SchemaVersion
but lowerCommitTs
is processed first. This behavior occurs because theddlJobPuller
processes DDL jobs based on theirCommitTs
in ascending order and uses a check againstSchemaVersion
that can prevent older DDL jobs from being processed, leading to data inconsistencies.Background:
The issue manifests when two DDL jobs are processed:
ALTER TABLE a ADD COLUMN x, y, z
withCommitTs
400ALTER TABLE b ADD COLUMN y
withCommitTs
300In this scenario, Job 62 is processed first due to its lower
CommitTs
. TheddlJobPuller
then updates itsSchemaVersion
to that of Job 62. When Job 60 is subsequently processed, the current logic discards it because itsSchemaVersion
is deemed older, even though itsCommitTs
is higher.This issue occurs because the
SchemaVersion
increment and job metadata write to TiKV are separate transactions. During a TiDB owner change, different instances might write these transactions without synchronization, leading to potential out-of-orderCommitTs
relative toSchemaVersion
.Solution:
To resolve this, the check on
SchemaVersion
is removed, ensuring that only theCommitTs
is verified:Updated Code:
Reasoning:
The
ResolvedTs
check ensures that only DDL jobs withFinishedTS
greater than the currentResolvedTs
are processed. Since theddlJobPuller
receives DDLs sorted byCommitTs
, any new DDL received with aFinishedTS
greater thanResolvedTs
must be handled, making theSchemaVersion
check redundant.Check List
Tests
Questions
Will it cause performance regression or break compatibility?
No.
Do you need to update user documentation, design documentation or monitoring documentation?
No.
Release note