Current Path : /home/usr.opt/mysql57/mysql-test/extra/rpl_tests/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
Current File : /home/usr.opt/mysql57/mysql-test/extra/rpl_tests/rpl_conflicts.test |
# ==== Purpose ==== # # Test that slave behaves well in some conflict situations. The # following are tested: # # - The slave SQL thread sees an 'INSERT' of a row with a key that # already exists in the table; # # - The slave SQL thread sees a 'DELETE' of a row that does not # exist in the table. # # In statement-logging mode, the first conflict type causes the slave # to stop with an error and the second conflict is ignored. # # In row-logging mode, the slave behavior depends the value of # @@slave_exec_mode on the slave: if @@slave_exec_mode is IDEMPOTENT, # the slave should ignore the conflicting statement and continue # normally. If @@slave_exec_mode is STRICT, the slave should stop # with an error. # # This test was previously named rpl_stm_mystery22/rpl_row_mystery22. # # # ==== Method ==== # # Create a table on master and slave, insert a row on slave, and # insert the same row on master. # # Create a table on master and slave, insert a row on master with # binlogging turned off, and remove the row on master with binlogging # turned on. # # # ==== Related bugs ==== # # BUG#31552: Replication breaks when deleting rows from out-of-sync table without PK # BUG#31609: Not all RBR slave errors reported as errors # # Bug in this test case: # BUG#37718: rpl.rpl_stm_mystery22 fails sporadically on pushbuild # # # ==== Usage ==== # # This file assumes the following: # # - The test language variable $slave_is_idempotent is set to 1 if the # slave is expected to stop on duplicate key errors (i.e., if the # binlog is in statement mode or # @@global.slave_exec_mode=STRICT). It is set to 0 otherwise. # # - Replication has been initialized by include/master-slave.inc # # - The test adds a suppression for the following warning: # Slave: Can't find record in 't1' Error_code: 1032 --echo ==== Initialize ==== --echo [on master] connection master; CREATE TABLE t1(a INT PRIMARY KEY); --echo [on slave] --source include/sync_slave_sql_with_master.inc --echo ==== Test: SQL thread sees 'INSERT' of existing key ==== --echo ---- Prepare slave so that it will get duplicate key error ---- # This row will be in the way of the row inserted by master. INSERT INTO t1 VALUES (1); --echo ---- Insert rows on master ---- --echo [on master] connection master; # Insert the same row on master INSERT INTO t1 VALUES (1); save_master_pos; SELECT * FROM t1; --echo [on slave] connection slave; # If we are statement-logging or if slave_exec_mode=STRICT, we now # expect to see an error on the slave. Otherwise (i.e., we are # row-logging and slave_exec_mode=IDEMPOTENT), we expect that the # duplicate row is ignored by the slave and replication continues. if (`SELECT @@global.binlog_format != 'ROW' OR @@global.slave_exec_mode = 'STRICT'`) { --echo ---- Wait until slave stops with an error ---- # Wait until the slave tries to run the query, fails with duplicate # key error, and stops the SQL thread. let $slave_sql_errno= convert_error(ER_DUP_ENTRY); source include/wait_for_slave_sql_error.inc; --let $errno= query_get_value("SHOW SLAVE STATUS", Last_SQL_Errno, 1) --eval SELECT "$errno" as 'Last_SQL_Errno' call mtr.add_suppression("Slave SQL.*Duplicate entry .1. for key .PRIMARY.* Error_code: 1062"); call mtr.add_suppression("The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state"); SELECT * FROM t1; --echo ---- Resolve the conflict on the slave and restart SQL thread ---- DELETE FROM t1 WHERE a = 1; START SLAVE SQL_THREAD; source include/wait_for_slave_sql_to_start.inc; } --echo ---- Sync slave and verify that there is no error ---- sync_with_master; --source include/check_slave_no_error.inc SELECT * FROM t1; --echo ==== Test: SQL thread sees 'DELETE' of non-existing row ==== --echo ---- On master, insert two rows, the second with binlogging off ---- --echo [on master] connection master; DELETE FROM t1; INSERT INTO t1 VALUES (1); --echo [on slave] --source include/sync_slave_sql_with_master.inc DELETE FROM t1 WHERE a = 1; --echo ---- On master, remove the row that does not exist on slave ---- --echo [on master] connection master; DELETE FROM t1 WHERE a = 1; SELECT * FROM t1; save_master_pos; --echo [on slave] connection slave; # If we are row-logging and slave_exec_mode is STRICT, we now expect # an error since the row to delete does not exist on slave. Otherwise # (i.e., either we are statement-logging or slave_exec_mode is # IDEMPOTENT), the absence of the row to delete is ignored and # replication continues. if (`SELECT @@global.binlog_format = 'ROW' AND @@global.slave_exec_mode = 'STRICT'`) { --echo ---- Wait until slave stops with an error ---- call mtr.add_suppression("Slave SQL.*Can.t find record in .t1., Error_code: 1032"); let $slave_sql_errno= convert_error(ER_KEY_NOT_FOUND); source include/wait_for_slave_sql_error.inc; --let $errno= query_get_value("SHOW SLAVE STATUS", Last_SQL_Errno, 1) --eval SELECT "$errno" as 'Last_SQL_Errno' SELECT * FROM t1; --echo ---- Resolve the conflict on the slave and restart SQL thread ---- INSERT INTO t1 VALUES (1); START SLAVE SQL_THREAD; source include/wait_for_slave_sql_to_start.inc; } --echo ---- Sync slave and verify that there is no error ---- # The slave should sync ok, and SHOW SLAVE STATUS should give no # error. sync_with_master; --source include/check_slave_no_error.inc SELECT * FROM t1; --echo ==== Clean up ==== --echo [on master] connection master; DROP TABLE t1; --echo [on slave] --source include/sync_slave_sql_with_master.inc