1 ################################
3 # Change Date: 2006-01-12
4 # Change: Added back have stm binlog
5 # and added requirments comments
6 ################################
7 # test case to make slave thread get ahead by 22 bytes
8 ################################
9 #REQUIREMENT: If there is a faked slave duplicate key insert
10 #error and the slave is restarted, the replication should
11 #proceed in a correct way.
12 ################################
13 #REQUIREMENT: If there is a faked slave non-existing record
14 #delete error and the slave is restarted, then the replication
15 #should proceed in a correct way.
16 #################################
18 -- source include/have_binlog_format_mixed_or_statement.inc
19 -- source include/master-slave.inc
21 # first, cause a duplicate key problem on the slave
22 create table t1(n int auto_increment primary key, s char(10));
23 sync_slave_with_master;
24 insert into t1 values (2,'old');
26 insert into t1 values(NULL,'new');
27 insert into t1 values(NULL,'new');
30 # wait until the slave tries to run the query, fails and aborts slave thread
31 wait_for_slave_to_stop;
32 select * from t1 order by n;
33 delete from t1 where n = 2;
38 #now the buggy slave would be confused on the offset but it can replicate
39 #in order to make it break, we need to stop/start the slave one more time
42 # to be able to really confuse the slave, we need some non-auto-increment
44 create table t2(n int);
46 insert into t1 values(NULL,'new');
47 # what happens when we delete a row which does not exist on slave?
49 insert into t1 values(NULL,'new');
51 delete from t1 where n=4;
57 #now the truth comes out - if the slave is buggy, it will never sync because
58 #the slave thread is not able to read events
60 select * from t1 order by n;
64 sync_slave_with_master;