Current Path : /home/usr.opt/mysql57/mysql-test/suite/engines/funcs/t/ |
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/suite/engines/funcs/t/rpl_stm_mystery22.test |
################################ # Change Author: JBM # Change Date: 2006-01-12 # Change: Added back have stm binlog # and added requirments comments ################################ # test case to make slave thread get ahead by 22 bytes ################################ #REQUIREMENT: If there is a faked slave duplicate key insert #error and the slave is restarted, the replication should #proceed in a correct way. ################################ #REQUIREMENT: If there is a faked slave non-existing record #delete error and the slave is restarted, then the replication #should proceed in a correct way. ################################# -- source include/have_binlog_format_mixed_or_statement.inc -- source include/master-slave.inc # first, cause a duplicate key problem on the slave create table t1(n int auto_increment primary key, s char(10)); sync_slave_with_master; insert into t1 values (2,'old'); connection master; insert into t1 values(NULL,'new'); insert into t1 values(NULL,'new'); save_master_pos; connection slave; # wait until the slave tries to run the query, fails and aborts slave thread wait_for_slave_to_stop; select * from t1 order by n; delete from t1 where n = 2; --disable_warnings start slave; --enable_warnings sync_with_master; #now the buggy slave would be confused on the offset but it can replicate #in order to make it break, we need to stop/start the slave one more time stop slave; connection master; # to be able to really confuse the slave, we need some non-auto-increment # events in the log create table t2(n int); drop table t2; insert into t1 values(NULL,'new'); # what happens when we delete a row which does not exist on slave? set sql_log_bin=0; insert into t1 values(NULL,'new'); set sql_log_bin=1; delete from t1 where n=4; save_master_pos; connection slave; --disable_warnings start slave; --enable_warnings #now the truth comes out - if the slave is buggy, it will never sync because #the slave thread is not able to read events sync_with_master; select * from t1 order by n; #clean up connection master; drop table t1; sync_slave_with_master; # End of 4.1 tests