mariadb/mysql-test/t/rpl_loaddata.test

130 lines
4.1 KiB
Text
Raw Normal View History

# See if replication of a "LOAD DATA in an autoincrement column"
# Honours autoincrement values
# i.e. if the master and slave have the same sequence
#
# check replication of load data for temporary tables with additional parameters
#
# check if duplicate entries trigger an error (they should unless IGNORE or
# REPLACE was used on the master) (bug 571).
#
# check if START SLAVE, RESET SLAVE, CHANGE MASTER reset Last_slave_error and
# Last_slave_errno in SHOW SLAVE STATUS (1st and 3rd commands did not: bug 986).
source include/master-slave.inc;
First commit for fixing BUG#1100 "LOAD DATA INFILE is badly filtered by binlog-*-db rules". There will probably be a second final one to merge Dmitri's changes to rpl_log.result and mine. 2 new tests: rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules, rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates. mysql-test/r/rpl_loaddata.result: Test that logging of LOAD DATA INFILE is done on the slave mysql-test/t/rpl_loaddata.test: Test that logging of LOAD DATA is done on the slave sql/log.cc: debug info sql/log_event.cc: * Append_block, Exec_load and Delete_file now have a member 'db' like Create_file. This member is filled by mysql_load(). It is used for filtering by binlog-*-db rules, that's all. It's not written to the binlog, and so can't be read from the binlog. In other words, that's temporary info which is stored in the event and lost when it is written and deleted. * Better error messages in Append_block et al. events. * The slave now logs (log-slave-updates) the Create_file et al. events in mysql_load() (they are not directly copied from the events in the relay log, because this prevented filtering by binlog-*-db rules). Before, mysql_load() in the slave did no logging, now it does the logging, as in any regular thread. sql/log_event.h: New member 'db' for Append_block et al. events. sql/slave.cc: Removed useless code. Why was it useless: - CREATE_FILE_EVENT is not defined in 3.23. It appeared in 4.0. - in queue_old_event(), which is called only if the master is 3.23, we had a case CREATE_FILE_EVENT: so this case can be removed. - this case was the only caller of process_io_create_file() so this function can be removed. sql/sql_load.cc: Pass the db to events, so that they can be well filtered. sql/sql_repl.cc: Pass the db to events so that they can be well filtered.
2003-08-20 23:24:45 +02:00
connection slave;
reset master;
connection master;
create table t1(a int not null auto_increment, b int, primary key(a) );
load data infile '../../std_data/rpl_loaddata.dat' into table t1;
create temporary table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60));
load data infile '../../std_data/rpl_loaddata2.dat' into table t2 fields terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by '\n##\n' starting by '>' ignore 1 lines;
create table t3 (day date,id int(9),category enum('a','b','c'),name varchar(60));
insert into t3 select * from t2;
save_master_pos;
connection slave;
sync_with_master;
select * from t1;
select * from t3;
First commit for fixing BUG#1100 "LOAD DATA INFILE is badly filtered by binlog-*-db rules". There will probably be a second final one to merge Dmitri's changes to rpl_log.result and mine. 2 new tests: rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules, rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates. mysql-test/r/rpl_loaddata.result: Test that logging of LOAD DATA INFILE is done on the slave mysql-test/t/rpl_loaddata.test: Test that logging of LOAD DATA is done on the slave sql/log.cc: debug info sql/log_event.cc: * Append_block, Exec_load and Delete_file now have a member 'db' like Create_file. This member is filled by mysql_load(). It is used for filtering by binlog-*-db rules, that's all. It's not written to the binlog, and so can't be read from the binlog. In other words, that's temporary info which is stored in the event and lost when it is written and deleted. * Better error messages in Append_block et al. events. * The slave now logs (log-slave-updates) the Create_file et al. events in mysql_load() (they are not directly copied from the events in the relay log, because this prevented filtering by binlog-*-db rules). Before, mysql_load() in the slave did no logging, now it does the logging, as in any regular thread. sql/log_event.h: New member 'db' for Append_block et al. events. sql/slave.cc: Removed useless code. Why was it useless: - CREATE_FILE_EVENT is not defined in 3.23. It appeared in 4.0. - in queue_old_event(), which is called only if the master is 3.23, we had a case CREATE_FILE_EVENT: so this case can be removed. - this case was the only caller of process_io_create_file() so this function can be removed. sql/sql_load.cc: Pass the db to events, so that they can be well filtered. sql/sql_repl.cc: Pass the db to events so that they can be well filtered.
2003-08-20 23:24:45 +02:00
# We want to be sure that LOAD DATA is in the slave's binlog.
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# But we can't simply read this binlog, because as the slave has not been
# restarted for this test, the file_id is uncertain (would cause test
# failures). So instead, we test if the binlog looks long enough to
First commit for fixing BUG#1100 "LOAD DATA INFILE is badly filtered by binlog-*-db rules". There will probably be a second final one to merge Dmitri's changes to rpl_log.result and mine. 2 new tests: rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules, rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates. mysql-test/r/rpl_loaddata.result: Test that logging of LOAD DATA INFILE is done on the slave mysql-test/t/rpl_loaddata.test: Test that logging of LOAD DATA is done on the slave sql/log.cc: debug info sql/log_event.cc: * Append_block, Exec_load and Delete_file now have a member 'db' like Create_file. This member is filled by mysql_load(). It is used for filtering by binlog-*-db rules, that's all. It's not written to the binlog, and so can't be read from the binlog. In other words, that's temporary info which is stored in the event and lost when it is written and deleted. * Better error messages in Append_block et al. events. * The slave now logs (log-slave-updates) the Create_file et al. events in mysql_load() (they are not directly copied from the events in the relay log, because this prevented filtering by binlog-*-db rules). Before, mysql_load() in the slave did no logging, now it does the logging, as in any regular thread. sql/log_event.h: New member 'db' for Append_block et al. events. sql/slave.cc: Removed useless code. Why was it useless: - CREATE_FILE_EVENT is not defined in 3.23. It appeared in 4.0. - in queue_old_event(), which is called only if the master is 3.23, we had a case CREATE_FILE_EVENT: so this case can be removed. - this case was the only caller of process_io_create_file() so this function can be removed. sql/sql_load.cc: Pass the db to events, so that they can be well filtered. sql/sql_repl.cc: Pass the db to events so that they can be well filtered.
2003-08-20 23:24:45 +02:00
# contain LOAD DATA. That is, I (Guilhem) have done SHOW BINLOG EVENTS on my
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# machine, saw that the binlog is of size 964 when things go fine.
# If LOAD DATA was not logged, the binlog would be shorter.
show master status;
connection master;
drop table t1;
drop table t2;
drop table t3;
create table t1(a int, b int, unique(b));
save_master_pos;
connection slave;
sync_with_master;
First commit for fixing BUG#1100 "LOAD DATA INFILE is badly filtered by binlog-*-db rules". There will probably be a second final one to merge Dmitri's changes to rpl_log.result and mine. 2 new tests: rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules, rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates. mysql-test/r/rpl_loaddata.result: Test that logging of LOAD DATA INFILE is done on the slave mysql-test/t/rpl_loaddata.test: Test that logging of LOAD DATA is done on the slave sql/log.cc: debug info sql/log_event.cc: * Append_block, Exec_load and Delete_file now have a member 'db' like Create_file. This member is filled by mysql_load(). It is used for filtering by binlog-*-db rules, that's all. It's not written to the binlog, and so can't be read from the binlog. In other words, that's temporary info which is stored in the event and lost when it is written and deleted. * Better error messages in Append_block et al. events. * The slave now logs (log-slave-updates) the Create_file et al. events in mysql_load() (they are not directly copied from the events in the relay log, because this prevented filtering by binlog-*-db rules). Before, mysql_load() in the slave did no logging, now it does the logging, as in any regular thread. sql/log_event.h: New member 'db' for Append_block et al. events. sql/slave.cc: Removed useless code. Why was it useless: - CREATE_FILE_EVENT is not defined in 3.23. It appeared in 4.0. - in queue_old_event(), which is called only if the master is 3.23, we had a case CREATE_FILE_EVENT: so this case can be removed. - this case was the only caller of process_io_create_file() so this function can be removed. sql/sql_load.cc: Pass the db to events, so that they can be well filtered. sql/sql_repl.cc: Pass the db to events so that they can be well filtered.
2003-08-20 23:24:45 +02:00
# See if slave stops when there's a duplicate entry for key error in LOAD DATA
insert into t1 values(1,10);
connection master;
load data infile '../../std_data/rpl_loaddata.dat' into table t1;
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
wait_for_slave_to_stop;
# Skip the bad event and see if error is cleared in SHOW SLAVE STATUS by START
# SLAVE, even though we are not executing any event (as sql_slave_skip_counter
# takes us directly to the end of the relay log).
set global sql_slave_skip_counter=1;
start slave;
sync_with_master;
--replace_result $MASTER_MYPORT MASTER_PORT
show slave status;
# Trigger error again to test CHANGE MASTER
connection master;
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
load data infile '../../std_data/rpl_loaddata.dat' into table t1;
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
wait_for_slave_to_stop;
# CHANGE MASTER and see if error is cleared in SHOW SLAVE STATUS.
stop slave;
change master to master_user='test';
change master to master_user='root';
--replace_result $MASTER_MYPORT MASTER_PORT
show slave status;
# Trigger error again to test RESET SLAVE
set global sql_slave_skip_counter=1;
start slave;
sync_with_master;
connection master;
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
load data infile '../../std_data/rpl_loaddata.dat' into table t1;
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
wait_for_slave_to_stop;
# RESET SLAVE and see if error is cleared in SHOW SLAVE STATUS.
stop slave;
reset slave;
--replace_result $MASTER_MYPORT MASTER_PORT
show slave status;
# Finally, see if logging is done ok on master for a failing LOAD DATA INFILE
connection master;
reset master;
create table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60),
unique(day));
--error 1062;
load data infile '../../std_data/rpl_loaddata2.dat' into table t2 fields
terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by
'\n##\n' starting by '>' ignore 1 lines;
# To test that there is Create_file & Delete_file, we test if the binlog is as
# long as expected (can't do SHOW BINLOG EVENTS because of varying file_id).
show master status;
drop table t2;