Skip to content

Conversation

cenkore
Copy link

@cenkore cenkore commented Apr 20, 2023

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-instruments to enable wait/lock/metadata/sql/mdl instrument. In atomic cut-over phase, add two channels okToDropSentryTable, dropSentryTableDone, the channel okToUnlockTable only do one thing that releasing the locks, after migrator receiving dropSentryTableDone channel, 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 is schema.table, but got schema._table_gho, then cancel the current cut-over, and try again.

Thank you!

@shlomi-noach
Copy link
Contributor

Can you please rephrase what this PR does? Or, if you could please illustrate by a sequence of events that cause the bug?

@shlomi-noach
Copy link
Contributor

Ah, sorry, I missed the link to #887

@blackhat12

This comment was marked as spam.

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.

4 participants