-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Allow use gh-ost on Galera / XtraDB cluster #780
base: master
Are you sure you want to change the base?
Conversation
11799b1
to
91b5c9d
Compare
@shlomi-noach I know you don't have a lot of free time lately but, could you at least look into the look at the approach and the possibility of adding a trigger-based cut-over? We are using it in production for a couple of months and it is showing some good results. If you have any questions, don't hesitate to let me know. |
02f75b7
to
27dce9f
Compare
27dce9f
to
9167ccf
Compare
@jfudally I don't know if you can tell me how feasible it would be to integrate this new cutover for galera / XtraDB In case it helps, I created a post some time ago explaining this particular case https://gonlo2.github.io/blog/en/blog/2020-03-04-why-dont-you-see-ghosts-in-galeras/ |
Unfortunately, I don't know enough about Galera to make a decision on this PR. /cc @timvaillancourt @gtowey maybe? |
Related issue: #224
Description
Currently gh-ost can't work on Galera-based MySQL like PXC because it needs to perform
LOCK TABLES
for bothatomic
andtwo-step
cut-over phase.A know workaround is to use
two-step
cut-over strategy but only with two not so common requirements:In order to use gh-ost without the above requirements, on all Galera-based systems I created a new cut-over strategy named
trigger
Using this option, during the cut-over phase, gh-ost will behave exactly like the well known tool pt-online-schema-change: adding triggers on the original table to keep the ghost one synchronised.
How it works
In order to have an atomic table swap without the use of a
LOCK TABLES
, three triggers are created during the cut-over phase, like what pt-online-schema-change does, and a special event is injected in the binlog to handle the write delegation phase from gh-ost to MySQL with triggers.gh-ost needs to handle that write delegation phase carefully because adding the triggers and stopping applying writes from gh-ost can't be done in the exact same moment or atomically.
After this delegation phase is necessary to sanitise all the write events occurred from the start to the end of that phase.
For manage safely this scenario the
trigger
cut-over strategy does this steps:Triggers
Even though gh-ost philosophy is avoid the use of triggers in Galera-based MySQL using this new cut-over gh-ost is able to archive a zero-error table swapping while supporting Galera-based MySQL with writes on multiple nodes, like in a common setup.
Given the cut-over phase should take very short time, it shouldn't be a problem to add triggers only in this phase.