fix issue 887

[cenkore]

Related issue: https://github.com/github/gh-ost/issues/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]

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]

Ah, sorry, I missed the link to https://github.com/github/gh-ost/issues/887

[blackhat12]

Klinux??

Pada tanggal Sel, 25 Apr 2023 15:57, Shlomi Noach @.***> menulis:

Ah, sorry, I missed the link to #887 https://github.com/github/gh-ost/issues/887

— Reply to this email directly, view it on GitHub https://github.com/github/gh-ost/pull/1269#issuecomment-1521334950, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMPJBA4U5EC5774VD2SOY3XC57XZANCNFSM6AAAAAAXFWQK6A . You are receiving this because you are subscribed to this thread.Message ID: @.***>