mariadb/mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test

55 lines
1.7 KiB
Text
Raw Normal View History

BUG#33029 5.0 to 5.1 replication fails on dup key when inserting using a trig in SP For all 5.0 and up to 5.1.12 exclusive, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value should not be written into the binary log, which means if a statement does not generate AUTO_INCREMENT value itself, there will be no Intvar event (SET INSERT_ID) associated with it even if one of the stored routine or trigger caused generation of such a value. And meanwhile, when executing a stored routine or trigger, it would ignore the INSERT_ID value even if there is a INSERT_ID value available set by a SET INSERT_ID statement. Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is written into the binary log, and the value will be used if available when executing the stored routine or trigger. Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12 (referenced as the buggy versions in the text below), when a statement that generates AUTO_INCREMENT value by the top statement was executed in the body of a SP, all statements in the SP after this statement would be treated as if they had generated AUTO_INCREMENT by the top statement. When a statement that did not generate AUTO_INCREMENT value by the top statement but by a function/trigger called by it, an erroneous Intvar event would be associated with the statement, this erroneous INSERT_ID value wouldn't cause problem when replicating between masters and slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID value was not used when executing functions/triggers. But when replicating from buggy versions to 5.1.12 or newer, which will use the INSERT_ID value in functions/triggers, the erroneous value will be used, which would cause duplicate entry error and cause the slave to stop. The patch for 5.1 fixed it to ignore the SET INSERT_ID value when executing functions/triggers if it is replicating from a master of buggy versions, another patch for 5.0 fixed it not to generate the erroneous Intvar event. mysql-test/include/show_binlog_events.inc: add $binlog_start parameter to show binlog events from a given position sql/slave.cc: Add function to check for bug#33029 sql/slave.h: Add function to check for bug#33029 sql/sql_class.cc: if master has bug#33029, reset auto_inc_intervals_forced for sub statements add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument sql/sql_class.h: Add member to save and restore auto_inc_intervals_forced sql/structs.h: add copy constructor and assignment operator for Discrete_intervals_list add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument mysql-test/std_data/bug33029-slave-relay-bin.000001: relay logs from a buggy 5.0 master for test case of BUG#33029 mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result: Test if the slave can process relay logs from a buggy master of BUG#33029 mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt: Test if the slave can process relay logs from a buggy master of BUG#33029 mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Test if the slave can process relay logs from a buggy master of BUG#33029
2008-03-14 11:35:41 +08:00
# BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
# using a trig in SP
# For all 5.0 up to 5.0.58 exclusive, and 5.1 up to 5.1.12 exclusive,
# if one statement in a SP generated AUTO_INCREMENT value by the top
# statement, all statements after it would be considered generated
# AUTO_INCREMENT value by the top statement, and a erroneous INSERT_ID
# value might be associated with these statement, which could cause
# duplicate entry error and stop the slave.
# Test if the slave can replicate from such a buggy master
# The bug33029-slave-relay-bin.000001 file is the
# slave-replay-bin.000003 file generated by run the
# rpl_auto_increment_bug33029.test with clean up statements at the end
# of the test case removed on a buggy 5.0 server
source include/have_log_bin.inc;
BUG#33029 5.0 to 5.1 replication fails on dup key when inserting using a trig in SP For all 5.0 and up to 5.1.12 exclusive, when a stored routine or trigger caused an INSERT into an AUTO_INCREMENT column, the generated AUTO_INCREMENT value should not be written into the binary log, which means if a statement does not generate AUTO_INCREMENT value itself, there will be no Intvar event (SET INSERT_ID) associated with it even if one of the stored routine or trigger caused generation of such a value. And meanwhile, when executing a stored routine or trigger, it would ignore the INSERT_ID value even if there is a INSERT_ID value available set by a SET INSERT_ID statement. Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is written into the binary log, and the value will be used if available when executing the stored routine or trigger. Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12 (referenced as the buggy versions in the text below), when a statement that generates AUTO_INCREMENT value by the top statement was executed in the body of a SP, all statements in the SP after this statement would be treated as if they had generated AUTO_INCREMENT by the top statement. When a statement that did not generate AUTO_INCREMENT value by the top statement but by a function/trigger called by it, an erroneous Intvar event would be associated with the statement, this erroneous INSERT_ID value wouldn't cause problem when replicating between masters and slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID value was not used when executing functions/triggers. But when replicating from buggy versions to 5.1.12 or newer, which will use the INSERT_ID value in functions/triggers, the erroneous value will be used, which would cause duplicate entry error and cause the slave to stop. The patch for 5.1 fixed it to ignore the SET INSERT_ID value when executing functions/triggers if it is replicating from a master of buggy versions, another patch for 5.0 fixed it not to generate the erroneous Intvar event. mysql-test/include/show_binlog_events.inc: add $binlog_start parameter to show binlog events from a given position sql/slave.cc: Add function to check for bug#33029 sql/slave.h: Add function to check for bug#33029 sql/sql_class.cc: if master has bug#33029, reset auto_inc_intervals_forced for sub statements add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument sql/sql_class.h: Add member to save and restore auto_inc_intervals_forced sql/structs.h: add copy constructor and assignment operator for Discrete_intervals_list add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument mysql-test/std_data/bug33029-slave-relay-bin.000001: relay logs from a buggy 5.0 master for test case of BUG#33029 mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result: Test if the slave can process relay logs from a buggy master of BUG#33029 mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt: Test if the slave can process relay logs from a buggy master of BUG#33029 mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: Test if the slave can process relay logs from a buggy master of BUG#33029
2008-03-14 11:35:41 +08:00
copy_file $MYSQL_TEST_DIR/std_data/bug33029-slave-relay-bin.000001 $MYSQLTEST_VARDIR/master-data/slave-relay-bin.000001;
write_file $MYSQLTEST_VARDIR/master-data/slave-relay-bin.index;
slave-relay-bin.000001
EOF
change master to
MASTER_HOST='dummy.localdomain',
RELAY_LOG_FILE='slave-relay-bin.000001',
RELAY_LOG_POS=4;
start slave sql_thread;
disable_result_log;
select MASTER_POS_WAIT('master-bin.000001', 3776);
enable_result_log;
echo # Result on slave;
SELECT * FROM t1;
SELECT * FROM t2;
# clean up
disable_warnings;
DROP TABLE IF EXISTS t1, t2;
DROP PROCEDURE IF EXISTS p1;
DROP PROCEDURE IF EXISTS p2;
DROP FUNCTION IF EXISTS f1;
DROP TRIGGER IF EXISTS tr1;
enable_warnings;
Bug #35675 reset master finds assert if a binlog file can not be deleted If a binlog file is manually replaced with a namesake directory the internal purging did not handle the error of deleting the file so that eventually a post-execution guards fires an assert. Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error at an attempt to delete it. The same applied to the index file deletion. The cset carries pieces of manual merging. mysql-test/r/binlog_index.result: new results mysql-test/r/ctype_big5.result: results changed mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result: new results mysql-test/suite/binlog/r/binlog_stm_blackhole.result: new results mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test: cleanup. still todo: to let the test run multiple times w/o restarting the server (just ./mtr test) mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result: results changed mysql-test/suite/rpl/t/rpl_stm_auto_increment_bug33029.test: guarding the test with statement format condition as the logics of the test requires sql/log.cc: two changes. One for the bug, other manual merge. The bug change needs MYF(0) to pass to my_delete because not all error out of the function are critical. The finer check is done on the caller of my_delete similarly how it was implemented for bug@18199 fixes. Non-existance of a file is not a critical error. sql/sql_class.cc: manual merge, removing extra automatically brought hunk.
2008-03-30 00:54:08 +02:00
remove_file $MYSQLTEST_VARDIR/master-data/slave-relay-bin.000001;
remove_file $MYSQLTEST_VARDIR/master-data/slave-relay-bin.index;
stop slave sql_thread;
let $keep_connection=1;
source include/wait_for_slave_sql_to_stop.inc;