mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 14:02:32 +01:00
e8e20954e6
Problem: rpl_stm_mystery22 is unstable. Reason: At one place, the test case *should* wait until the SQL thread on the slave receives an error, but instead it waits until the SQL thread stops. The SQL thread may stop before the error flag is set, so that when the test case continues to execute, the error flag is not set. Fix: Introduce the subroutine mysql-test/include/wait_for_slave_sql_error.inc, which waits until there is an error in the sql thread of the slave. Re-commit: fixed one logical error and two smaller things noted by Mats. mysql-test/suite/rpl/t/rpl_stm_mystery22.test: Use the new wait_for_slave_sql_error.inc instead of wait_for_slave_to_stop. There may be a delay from when the slave stops to when Last_SQL_Errno is set, so it is not safe to merely wait until the slave stops. mysql-test/include/wait_for_slave_sql_error.inc: New BitKeeper file ``mysql-test/include/wait_for_slave_sql_error.inc'' This is a subroutine that waits until the sql thread on the slave receives an error, as indicated by Last_SQL_Errno in "SHOW SLAVE STATUS".
66 lines
2.1 KiB
Text
66 lines
2.1 KiB
Text
################################
|
|
# 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
|
|
source include/wait_for_slave_sql_error.inc;
|
|
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
|