mariadb/mysql-test/t/rpl_loaddata_map.test

53 lines
1.5 KiB
Text
Raw Normal View History

BUG#30435 loading large LOAD DATA INFILE breaks slave with read_buffer_size set on master BUG#33413 show binlog events fails if binlog has event size of close to max_allowed_packet The size of Append_block replication event was determined solely by read_buffer_size whereas the rest of replication code deals with max_allowed_packet. When the former parameter was set to larger than the latter there were two artifacts: the master could not read events from binlog; show master events did not show. Fixed with - fragmenting the used io-cached buffer into pieces each size of less than max_allowed_packet (bug#30435) - incrementing show-binlog-events handling thread's max_allowed_packet with the max estimated for the replication header size include/my_sys.h: accessor-macros added in order not to mess with the io cache's implementation details in code that merely exploits the io-cache. sql/sql_repl.cc: BUG#33413: incrementing thd->variables.max_allowed_packet with the max estimation for the replication header size (from bug#19402); refactoring log_loaded_block() to fragment the io_cache buffer in case read_buffer_size > max_allowed_packet. mysql-test/r/rpl_loaddata_map.result: New BitKeeper file ``mysql-test/r/rpl_loaddata_map.result'' mysql-test/t/rpl_loaddata_map-master.opt: specific options to trigger BUG#30435, BUG#33413 situations mysql-test/t/rpl_loaddata_map-slave.opt: max_allowed_packet to be compatible with the master's version. mysql-test/t/rpl_loaddata_map.test: regression tests for two bugs.
2007-12-21 21:34:43 +01:00
#
# check replication of load data with the server parameters subjected to
# read_buffer_size > max_allowed_packet
#
# BUG#30435 loading large LOAD DATA INFILE breaks slave with
# read_buffer_size set on master
# BUG#33413 show binlog events fails if binlog has event size of close
# to max_allowed_packet
source include/master-slave.inc;
source include/have_innodb.inc;
--disable_query_log
let $rows= 5000;
create table t1 (id int not null primary key auto_increment);
while($rows)
{
eval insert into t1 values (null);
dec $rows;
}
eval select * into outfile '$MYSQLTEST_VARDIR/tmp/bug30435_5k.txt' from t1;
flush logs;
--enable_query_log
connection master;
create table t2 (id int not null primary key auto_increment);
select @@session.read_buffer_size - @@session.max_allowed_packet > 0 ;
BUG#30435 loading large LOAD DATA INFILE breaks slave with read_buffer_size set on master BUG#33413 show binlog events fails if binlog has event size of close to max_allowed_packet The size of Append_block replication event was determined solely by read_buffer_size whereas the rest of replication code deals with max_allowed_packet. When the former parameter was set to larger than the latter there were two artifacts: the master could not read events from binlog; show master events did not show. Fixed with - fragmenting the used io-cached buffer into pieces each size of less than max_allowed_packet (bug#30435) - incrementing show-binlog-events handling thread's max_allowed_packet with the max estimated for the replication header size include/my_sys.h: accessor-macros added in order not to mess with the io cache's implementation details in code that merely exploits the io-cache. sql/sql_repl.cc: BUG#33413: incrementing thd->variables.max_allowed_packet with the max estimation for the replication header size (from bug#19402); refactoring log_loaded_block() to fragment the io_cache buffer in case read_buffer_size > max_allowed_packet. mysql-test/r/rpl_loaddata_map.result: New BitKeeper file ``mysql-test/r/rpl_loaddata_map.result'' mysql-test/t/rpl_loaddata_map-master.opt: specific options to trigger BUG#30435, BUG#33413 situations mysql-test/t/rpl_loaddata_map-slave.opt: max_allowed_packet to be compatible with the master's version. mysql-test/t/rpl_loaddata_map.test: regression tests for two bugs.
2007-12-21 21:34:43 +01:00
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
BUG#30435 loading large LOAD DATA INFILE breaks slave with read_buffer_size set on master BUG#33413 show binlog events fails if binlog has event size of close to max_allowed_packet The size of Append_block replication event was determined solely by read_buffer_size whereas the rest of replication code deals with max_allowed_packet. When the former parameter was set to larger than the latter there were two artifacts: the master could not read events from binlog; show master events did not show. Fixed with - fragmenting the used io-cached buffer into pieces each size of less than max_allowed_packet (bug#30435) - incrementing show-binlog-events handling thread's max_allowed_packet with the max estimated for the replication header size include/my_sys.h: accessor-macros added in order not to mess with the io cache's implementation details in code that merely exploits the io-cache. sql/sql_repl.cc: BUG#33413: incrementing thd->variables.max_allowed_packet with the max estimation for the replication header size (from bug#19402); refactoring log_loaded_block() to fragment the io_cache buffer in case read_buffer_size > max_allowed_packet. mysql-test/r/rpl_loaddata_map.result: New BitKeeper file ``mysql-test/r/rpl_loaddata_map.result'' mysql-test/t/rpl_loaddata_map-master.opt: specific options to trigger BUG#30435, BUG#33413 situations mysql-test/t/rpl_loaddata_map-slave.opt: max_allowed_packet to be compatible with the master's version. mysql-test/t/rpl_loaddata_map.test: regression tests for two bugs.
2007-12-21 21:34:43 +01:00
eval load data infile '$MYSQLTEST_VARDIR/tmp/bug30435_5k.txt' into table t2;
select count(*) from t2 /* 5 000 */;
# the binglog will show fragmented Append_block events
--let $binlog_start=98
--replace_column 5 #
--replace_regex /\/\* xid=.* \*\//\/* XID *\// /file_id=[0-9]+/file_id=#/
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
BUG#30435 loading large LOAD DATA INFILE breaks slave with read_buffer_size set on master BUG#33413 show binlog events fails if binlog has event size of close to max_allowed_packet The size of Append_block replication event was determined solely by read_buffer_size whereas the rest of replication code deals with max_allowed_packet. When the former parameter was set to larger than the latter there were two artifacts: the master could not read events from binlog; show master events did not show. Fixed with - fragmenting the used io-cached buffer into pieces each size of less than max_allowed_packet (bug#30435) - incrementing show-binlog-events handling thread's max_allowed_packet with the max estimated for the replication header size include/my_sys.h: accessor-macros added in order not to mess with the io cache's implementation details in code that merely exploits the io-cache. sql/sql_repl.cc: BUG#33413: incrementing thd->variables.max_allowed_packet with the max estimation for the replication header size (from bug#19402); refactoring log_loaded_block() to fragment the io_cache buffer in case read_buffer_size > max_allowed_packet. mysql-test/r/rpl_loaddata_map.result: New BitKeeper file ``mysql-test/r/rpl_loaddata_map.result'' mysql-test/t/rpl_loaddata_map-master.opt: specific options to trigger BUG#30435, BUG#33413 situations mysql-test/t/rpl_loaddata_map-slave.opt: max_allowed_packet to be compatible with the master's version. mysql-test/t/rpl_loaddata_map.test: regression tests for two bugs.
2007-12-21 21:34:43 +01:00
--eval show binlog events in 'master-bin.000002' from $binlog_start
sync_slave_with_master;
#connection slave;
select count(*) from t2 /* 5 000 */;
connection master;
drop table t1, t2;
sync_slave_with_master;
remove_file $MYSQLTEST_VARDIR/tmp/bug30435_5k.txt;
--echo end of the tests