-
Frazer Clement authored
Fix which monitors the epochs received from the immediately upstream master, determined by server_id column == server_id metadata. Specifically, an observed epoch decline will have different results depending on the state of the Slave SQL thread. 1. Just after a RESET SLAVE statement No effect 2. Just after a START SLAVE statement A warning is produced 3. None of the above. The Slave SQL thread will stop. The intention with 1) is to enable warning free setting. The intention with 2) is to warn when a Slave is being positioned on a previously applied epoch. The intention with 3) is to stop the Slave when there is some system malfunction resulting in the re-application of an existing epoch. Testing is performed using error insertion on the upstream master. A new testcase, ndb_rpl_slave_replay is added to the ndb_rpl suite.
Frazer Clement authoredFix which monitors the epochs received from the immediately upstream master, determined by server_id column == server_id metadata. Specifically, an observed epoch decline will have different results depending on the state of the Slave SQL thread. 1. Just after a RESET SLAVE statement No effect 2. Just after a START SLAVE statement A warning is produced 3. None of the above. The Slave SQL thread will stop. The intention with 1) is to enable warning free setting. The intention with 2) is to warn when a Slave is being positioned on a previously applied epoch. The intention with 3) is to stop the Slave when there is some system malfunction resulting in the re-application of an existing epoch. Testing is performed using error insertion on the upstream master. A new testcase, ndb_rpl_slave_replay is added to the ndb_rpl suite.
Loading