1
0
mirror of https://github.com/MariaDB/server.git synced 2025-11-12 10:22:39 +03:00
Files
mariadb/mysql-test/t/rpl_log.test
unknown 20901edafb Remove wrong bug fix when calling create_sort_index.
Fix possible replication bug with LOAD DATA ... IGNORE LINES #


mysql-test/r/rpl_log.result:
  Test of load data ... ignore # lines
mysql-test/t/rpl_log.test:
  Test of load data ... ignore # lines
sql/log_event.cc:
  Fix replication bug with LOAD DATA ... IGNORE LINES #
  (Note that the code that is probably not executed in 4.0)
sql/sql_parse.cc:
  Indentation fix
sql/sql_select.cc:
  Remove wrong bug fix (all tests passes)
sql/sql_yacc.yy:
  Indentation cleanup
2003-08-10 05:14:16 +03:00

89 lines
3.2 KiB
Plaintext

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 ignore 1 lines;
select count(*) from 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;