You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you think about running SET SESSION sql_log_bin=0 before applying changes when running in --test-on-replica mode? Right now, after testing on a replica, we need to wipe it and restore it from scratch (to prevent any invalid GTIDs from creeping in the event of a later promotion of that host to master). This is kind of irritating, and if we just turn off binlogging for that session, we wouldn't necessarily have to reset the box afterwards.
The text was updated successfully, but these errors were encountered:
I'm good to set a --sql-log-bin=false command line option.
One problem I see right now is the writes to _tbl_ghc -- the changelog table. In particular, the indication that the sync is complete (during cut-over phase) is done by updating a row on the changelog table, then picking that statement in the binary log. That's what promises us our async operation is truly complete and all other events have been processed.
And so there's at least one single update that needs to be made on the replica, which kinda ruins everything, correct?
For the specific use case of --test-on-replica we can work around this ; however such will not be the case for --migrate-on-replica, I suspect.
What would you think about running
SET SESSION sql_log_bin=0
before applying changes when running in--test-on-replica
mode? Right now, after testing on a replica, we need to wipe it and restore it from scratch (to prevent any invalid GTIDs from creeping in the event of a later promotion of that host to master). This is kind of irritating, and if we just turn off binlogging for that session, we wouldn't necessarily have to reset the box afterwards.The text was updated successfully, but these errors were encountered: