mariadb/mysql-test/t/rpl_log.test
unknown 546b2221a2 A trick (a useless update) to force the slave to wait for TWO rotate events
before stopping. This is to make the test's result predictable (depending
on the machine the results could formerly be slightly different, though
everything is sane in the code; it's not a bug).


mysql-test/r/rpl_log.result:
  result update
2003-05-27 23:07:32 +02:00

87 lines
3.2 KiB
Text

source include/master-slave.inc;
#clean up slave binlogs
connection slave;
slave stop;
reset master;
reset slave;
let $VERSION=`select version()`;
connection master;
reset master;
create table t1(n int not null auto_increment primary key);
insert into t1 values (NULL);
drop table t1;
create table t1 (word char(20) not null);
load data infile '../../std_data/words.dat' into table t1;
drop table t1;
--replace_result $VERSION VERSION
show binlog events;
show binlog events from 79 limit 1;
show binlog events from 79 limit 2;
show binlog events from 79 limit 2,1;
flush logs;
# We need an extra update before doing save_master_pos.
# Otherwise, an unlikely scenario may occur:
# * When the master's binlog_dump thread reads the end of master-bin.001,
# it send the rotate event which is at this end, plus a fake rotate event
# because it's starting to read a new binlog.
# save_master_pos will record the position of the first of the two rotate
# (because the fake one is not in the master's binlog anyway).
# * Later the slave waits for the position of the first rotate event,
# and it may quickly stop (in 'slave stop') without having received the fake
# one.
# So, depending on a few milliseconds, we end up with 2 rotate events in the
# relay log or one, which influences the output of SHOW SLAVE STATUS, making
# it not predictable and causing random test failures.
# To make it predictable, we do a useless update now, but which has the interest
# of making the slave catch both rotate events.
create table t5 (a int);
drop table t5;
# Sync slave and force it to start on another binary log
save_master_pos;
connection slave;
# Note that the above 'slave start' will cause a 3rd rotate event (a fake one)
# to go into the relay log (the master always sends a fake one when replication
# starts).
slave start;
sync_with_master;
flush logs;
slave stop;
connection master;
# Create some entries for second log
create table t1 (n int);
insert into t1 values (1);
drop table t1;
--replace_result $VERSION VERSION
show binlog events;
show binlog events in 'master-bin.002';
show master logs;
save_master_pos;
connection slave;
slave start;
sync_with_master;
show master logs;
--replace_result 3306 MASTER_PORT 9306 MASTER_PORT 3334 MASTER_PORT 3336 MASTER_PORT $VERSION VERSION
show binlog events in 'slave-bin.001' from 4;
--replace_result 3306 MASTER_PORT 9306 MASTER_PORT 3334 MASTER_PORT 3336 MASTER_PORT $VERSION VERSION
show binlog events in 'slave-bin.002' from 4;
--replace_result 3306 MASTER_PORT 9306 MASTER_PORT 3334 MASTER_PORT 3336 MASTER_PORT
show slave status;
# Need to recode the following
#show new master for slave with master_log_file='master-bin.001' and master_log_pos=4 and master_server_id=1;
#show new master for slave with master_log_file='master-bin.001' and master_log_pos=79 and master_server_id=1;
#show new master for slave with master_log_file='master-bin.001' and master_log_pos=311 and master_server_id=1;
#show new master for slave with master_log_file='master-bin.002' and master_log_pos=4 and master_server_id=1;
#show new master for slave with master_log_file='master-bin.002' and master_log_pos=122 and master_server_id=1;
--error 1220
show binlog events in 'slave-bin.005' from 4;