config root man

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
Upload File :
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

Man Man