Support triggers [community contribution welcome] about gh-ost HOT 6 OPEN

in the meantime, it might be nice to have a --yes-it-has-triggers-ignore-them option... I'm looking at a 300 GB table which has triggers that I am happy to deal with manually... #152 made gh-ost check and bail on presence of triggers. a method of explicitly overriding that behavior would help greatly

from gh-ost.

@allixsenos can you please open a new issue for this so we can track it?

from gh-ost.

"Preferably the triggers are read at migration start, not at cut-over phase" - why?

Surely reading them at the point you want to recreate them is more correct (what if a trigger is altered during a migration)?

from gh-ost.

@MarkLeith you are correct. My initial thought was to save time. The cut-over phase is the time where tables are locked, and I am a bit afraid of spending this time on even more operations.

I can also argue that anyone modifying the triggers while migration is running is on the right track to shooting themselves in the foot.

Having said all that the most ultimatest correctest behavior is to read trigger info while cutting over.

from gh-ost.

@shlomi-noach Are there any new insights into this issue? I am interested to give it a try.

from gh-ost.

@bancer no new insights on my side; I haven't given this thought.

from gh-ost.