Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[improve](backup) Add the commit seq at the backup job level. #44049 #44111

Merged
merged 1 commit into from
Nov 19, 2024

Conversation

w41ter
Copy link
Contributor

@w41ter w41ter commented Nov 18, 2024

cherry pick from #44049

@w41ter
Copy link
Contributor Author

w41ter commented Nov 18, 2024

run buildall

@doris-robot
Copy link

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

…#44049)

Related PR: selectdb/ccr-syncer#237

Problem Summary:

When a backup job is created, it will read the database and obtain a set
of table refs. If there is a table creation statement running
simultaneously and the new table is not included in the table refs, then
the job commit seq obtained by the CCR syncer only through the commit
seq of the tables included in the snapshot may be greater than that of
the new table. Consequently, the table will be lost during the
synchronization process.

This PR acquires a commit seq within the database read lock as the
commit seq of the entire snapshot. In this way, the CCR syncer can
continue to synchronize the binlog starting from this value. Thus, the
table creation statements running in parallel with the backup job will
either be included in the table refs or their binlog can be observed by
the snapshot commit sequence.
@w41ter w41ter force-pushed the pick_44049_to_origin_branch-2.0 branch from f457e85 to 0e03cdc Compare November 19, 2024 02:20
@w41ter
Copy link
Contributor Author

w41ter commented Nov 19, 2024

run buildall

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@w41ter w41ter merged commit f5d2993 into apache:branch-2.0 Nov 19, 2024
20 of 23 checks passed
@w41ter w41ter deleted the pick_44049_to_origin_branch-2.0 branch November 19, 2024 04:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants