snapshot (ticdc): reduce list tables time consumption (#11095) #11126
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 #11095
What problem does this PR solve?
Issue Number: close #11124
ref #11109
What is changed and how it works?
This approach can reduce time costs by minimizing the amount of data that needs to be loaded.
Check List
Tests
Covered by existed unit tests.
Test Environment
1 TiDB cluster(4000 tables in database
test
), 1 TiCDC.Test Result
Create 100 changefeeds using the configuration provided below:
Each changefeed will replicate 56 tables.
Before this PR, when the CDC server was restarted, the lag for changefeeds increased to approximately 1.5 minutes.
It took around 2.5 seconds to initialize the schema snapshot for each changefeed, as shown in the log below:
After implementing this PR, the lag for changefeeds increased to about 50 seconds when the CDC server was restarted.
It now takes approximately 1.4 seconds to initialize the schema snapshot for each changefeed. The log for this will be shown below.
However, if the changefeed aims to replicate all 4000 tables in db, this PR might be slightly slower by 0.5s compared to the version without this PR, as it needs to load the raw table schemas twice. This issue can be addressed by solution 2, as elaborated in #11109, which I will implement later.
Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note