What we did for the ping-ponged events between dual master instances, is just detect this case and print some warning/error into error.log, then DBA could handle it manually.
The main purpose is to just DETECT, but not FIX, though we could just delete the event before writing to relay log, but it's not what we expected for product environment.
We updated the patch for online MySQLs, which is more clear:
1. the rpl_circular_warning switch is opened automated once slave is registered.
2. rpl_circular_warning switch is turned off automated once detect the abnormal event.
The test case passed even no source code patch :)
$./mtr suite/rpl/ t/rpl_circular_ event_detect. test
======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= =
TEST RESULT TIME (ms) or COMMENT ------- ------- ------- ------- ------- ------- ------- ------- ------- ----
-------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009 circular_ event_detect 'mix' [ pass ] 1461 circular_ event_detect 'row' [ pass ] 1366 circular_ event_detect 'stmt' [ pass ] 1458 ------- ------- ------- ------- ------- ------- ------- ------- ------- ----
rpl.rpl_
rpl.rpl_
rpl.rpl_
-------
What we did for the ping-ponged events between dual master instances, is just detect this case and print some warning/error into error.log, then DBA could handle it manually.
The main purpose is to just DETECT, but not FIX, though we could just delete the event before writing to relay log, but it's not what we expected for product environment.
We updated the patch for online MySQLs, which is more clear:
1. the rpl_circular_ warning switch is opened automated once slave is registered. warning switch is turned off automated once detect the abnormal event.
2. rpl_circular_