1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
################################
# 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
|
