Open
Conversation
added 3 commits
April 20, 2023 22:15
Contributor
|
Can you please rephrase what this PR does? Or, if you could please illustrate by a sequence of events that cause the bug? |
Contributor
|
Ah, sorry, I missed the link to #887 |
This comment was marked as spam.
This comment was marked as spam.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Related issue: #887
Description
This PR adds a detection of whether rename session is acquiring the lock of the original table, to avoid data loss caused by directly unlock tables after drop magic table while rename session is still acquiring the lock of the ghost table in the atomic cut-over phase. The detection method via enable the instrument wait/lock/metadata/sql/mdl.
Here add a parameter
allow-setup-metadata-lock-instrumentsto enable wait/lock/metadata/sql/mdl instrument. In atomic cut-over phase, add two channelsokToDropSentryTable,dropSentryTableDone, the channelokToUnlockTableonly do one thing that releasing the locks, aftermigratorreceivingdropSentryTableDonechannel, then detect whether rename session is ready (acquire original table lock) or not. If not, you will get a message like the follows, Expect rename session xxxxx acquiring table metadata lock isschema.table, but gotschema._table_gho, then cancel the current cut-over, and try again.Thank you!