avoid to send drop cutover sentry table to mysql twice v2 #745
Conversation
atomicCutOver use tableUnlocked to wait AtomicCutOverMagicLock completed, avoid to concurrency call AtomicCutOverMagicLock come from retrying atomicCutOver
There was a problem hiding this comment.
Hi @MOON-CLJ and sorry for the late reply.
I think your change preserves the current behavior. However, I do not see how it prevents MTS from running the potential two drops in the same transaction again. The two drops, even as both created in the same function AtomicCutOverMagicLock(), can (and I expect that will) be applied by two different connections. Thus, replication stream can still pick those two drops in MTS.
|
@shlomi-noach yes, you're right。 can we just delete the logic "defer this.DropAtomicCutOverSentryTableIfExists()"? because a successful cutover will drop the sentry table eventually。or do you have any other idea? ps, even this bug is even more a MTS's bug，i am thinking what can we do in gh-ost to eliminate the pain。 |
|
OK, a less-pretty and yet simple solution is to protect the dropping of the table by a mutex, and always skip the 2nd operation. It is imperative that the table is dropped no matter what, which is why the |
|
@shlomi-noach "to protect the dropping of the table by a mutex", yes, can i gave another pr for this? |
|
@MOON-CLJ sure, thank you! |
2 participants
this pr is another way to deal with issue: #737
the first two commits are the same as #743 ，instead use get_lock，this pr use tableUnlocked channel to sync。