mariadb/mysql-test/extra/rpl_tests/rpl_insert_delayed.test

141 lines
3.8 KiB
Text
Raw Normal View History

Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
# The two bugs below (BUG#25507 and BUG#26116) existed only in
# statement-based binlogging; we test that now they are fixed;
# we also test that mixed and row-based binlogging work too,
# for completeness.
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
connection master;
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
--disable_warnings
CREATE SCHEMA IF NOT EXISTS mysqlslap;
USE mysqlslap;
--enable_warnings
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
select @@global.binlog_format;
#
# BUG#25507 "multi-row insert delayed + auto increment causes
# duplicate key entries on slave";
# happened only in statement-based binlogging.
#
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
CREATE TABLE t1 (id INT primary key auto_increment, name VARCHAR(64));
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
let $query = "INSERT DELAYED INTO t1 VALUES (null, 'Dr. No'), (null, 'From Russia With Love'), (null, 'Goldfinger'), (null, 'Thunderball'), (null, 'You Only Live Twice')";
--exec $MYSQL_SLAP --silent --concurrency=5 --iterations=200 --query=$query --delimiter=";"
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
FLUSH TABLE t1; # another way to be sure INSERT DELAYED has inserted
SELECT COUNT(*) FROM t1;
# when bug existed slave failed below ("duplicate key" error at random INSERT)
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
sync_slave_with_master;
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
use mysqlslap;
SELECT COUNT(*) FROM t1;
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
#
# BUG#26116 "If multi-row INSERT DELAYED has errors,
# statement-based binlogging breaks";
# happened only in statement-based binlogging.
#
connection master;
truncate table t1;
# first scenario: duplicate on first row
insert delayed into t1 values(10, "my name");
if ($binlog_format_statement)
{
# statement below will be converted to non-delayed INSERT and so
# will stop at first error, guaranteeing replication.
Bug #28842 Different 'duplicate key' error code between 5.0 and 5.1 The patch for WL 1563 added a new duplicate key error message so that the key name could be provided instead of the key number. But the error code for the new message was used even though that did not need to change. This could cause unnecessary problems for applications that used the old ER_DUP_ENTRY error code to detect duplicate key errors. mysql-test/t/auto_increment.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/create.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/create_select_tmp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ctype_ucs2_def.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ctype_utf8.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/delayed.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap_btree.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap_hash.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/innodb.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/insert_select.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/insert_update.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/join_outer.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/key.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/merge.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/myisam.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_basic.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_charset.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_index_unique.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_insert.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_replace.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_update.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/replace.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_err_ignoredtable.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_ndb_do_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_row_create_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_sp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/show_check.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp-error.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp_trans.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp_trans_log.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/temp_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_binary.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_bit.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_bit_innodb.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_blob.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_varchar.test: Update ER_DUP_ENTRY-related error message values mysql-test/r/create.result: Update ER_DUP_ENTRY-related error message values mysql-test/r/rpl_sp.result: Update ER_DUP_ENTRY-related error message values mysql-test/r/sp.result: Update ER_DUP_ENTRY-related error message values mysql-test/include/mix1.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/mix2.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/ps_modify.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/query_cache.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/varchar.inc: Update ER_DUP_ENTRY-related error message values mysql-test/extra/binlog_tests/insert_select-binlog.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_auto_increment.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_foreign_key.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_delayed.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_id.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_id_pk.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_loaddata.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_row_basic.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_stm_EE_err2.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_trig004.test: Update ER_DUP_ENTRY-related error message values sql/handler.cc: Restore use of ER_DUP_ENTRY error code even when ER_DUP_ENTRY_WITH_KEY_NAME error message is being used. (Bug #28842)
2007-06-06 19:57:07 +02:00
--error ER_DUP_ENTRY
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
insert delayed into t1 values(10, "is Bond"), (20, "James Bond");
}
if (!$binlog_format_statement)
{
insert delayed into t1 values(10, "is Bond"), (20, "James Bond");
}
flush table t1; # to wait for INSERT DELAYED to be done
select * from t1;
sync_slave_with_master;
# when bug existed in statement-based binlogging, t1 on slave had
# different content from on master
select * from t1;
# second scenario: duplicate on second row
connection master;
delete from t1 where id!=10;
if ($binlog_format_statement)
{
# statement below will be converted to non-delayed INSERT and so
# will be binlogged with its ER_DUP_ENTRY error code, guaranteeing
# replication (slave will hit the same error code and so be fine).
Bug #28842 Different 'duplicate key' error code between 5.0 and 5.1 The patch for WL 1563 added a new duplicate key error message so that the key name could be provided instead of the key number. But the error code for the new message was used even though that did not need to change. This could cause unnecessary problems for applications that used the old ER_DUP_ENTRY error code to detect duplicate key errors. mysql-test/t/auto_increment.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/create.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/create_select_tmp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ctype_ucs2_def.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ctype_utf8.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/delayed.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap_btree.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/heap_hash.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/innodb.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/insert_select.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/insert_update.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/join_outer.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/key.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/merge.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/myisam.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_basic.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_charset.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_index_unique.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_insert.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_replace.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/ndb_update.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/replace.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_err_ignoredtable.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_ndb_do_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_row_create_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/rpl_sp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/show_check.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp-error.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp_trans.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/sp_trans_log.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/temp_table.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_binary.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_bit.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_bit_innodb.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_blob.test: Update ER_DUP_ENTRY-related error message values mysql-test/t/type_varchar.test: Update ER_DUP_ENTRY-related error message values mysql-test/r/create.result: Update ER_DUP_ENTRY-related error message values mysql-test/r/rpl_sp.result: Update ER_DUP_ENTRY-related error message values mysql-test/r/sp.result: Update ER_DUP_ENTRY-related error message values mysql-test/include/mix1.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/mix2.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/ps_modify.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/query_cache.inc: Update ER_DUP_ENTRY-related error message values mysql-test/include/varchar.inc: Update ER_DUP_ENTRY-related error message values mysql-test/extra/binlog_tests/insert_select-binlog.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_auto_increment.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_foreign_key.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_delayed.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_id.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_insert_id_pk.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_loaddata.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_row_basic.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_stm_EE_err2.test: Update ER_DUP_ENTRY-related error message values mysql-test/extra/rpl_tests/rpl_trig004.test: Update ER_DUP_ENTRY-related error message values sql/handler.cc: Restore use of ER_DUP_ENTRY error code even when ER_DUP_ENTRY_WITH_KEY_NAME error message is being used. (Bug #28842)
2007-06-06 19:57:07 +02:00
--error ER_DUP_ENTRY
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
insert delayed into t1 values(20, "is Bond"), (10, "James Bond");
}
if (!$binlog_format_statement)
{
insert delayed into t1 values(20, "is Bond"), (10, "James Bond");
}
flush table t1; # to wait for INSERT DELAYED to be done
select * from t1;
sync_slave_with_master;
# when bug existed in statement-based binlogging, query was binlogged
# with error_code=0 so slave stopped
select * from t1;
# clean up
connection master;
Manual merge from 5.0-rpl, of fixes for: 1) BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: in statement-based binlogging, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. This is supposed to not affect many 5.1 users as in 5.1, the default binlog format is "mixed", which does not have the bug (the bug is only with binlog_format=STATEMENT). We should document how the system delayed_insert thread decides of its binlog format (which is not modified by this patch): this decision is taken when the thread is created and holds until it is terminated (is not affected by any later change via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog format of the connection which issues INSERT DELAYED (this binlog format does not affect how the row will be binlogged). If one wants to change the binlog format of its server with SET GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all delayed_insert threads terminate and thus new threads are created, taking into account the new format. 2) BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values". When in an INSERT ON DUPLICATE KEY UPDATE, using an autoincrement column, we inserted some autogenerated values and also updated some rows, some autogenerated values were not used (for example, even if 10 was the largest autoinc value in the table at the start of the statement, 12 could be the first autogenerated value inserted by the statement, instead of 11). One autogenerated value was lost per updated row. Led to exhausting the range of the autoincrement column faster. Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12. This bug breaks replication from a pre-5.0.24/pre-5.1.12 master. But the present bugfix, as it makes INSERT ON DUP KEY UPDATE behave like pre-5.0.24/pre-5.1.12, breaks replication from a [5.0.24,5.0.34]/[5.1.12,5.1.15] master to a fixed (5.0.36/5.1.16) slave! To warn users against this when they upgrade their slave, as agreed with the support team, we add code for a fixed slave to detect that it is connected to a buggy master in a situation (INSERT ON DUP KEY UPDATE into autoinc column) likely to break replication, in which case it cannot replicate so stops and prints a message to the slave's error log and to SHOW SLAVE STATUS. For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15] replication we cannot warn as master does not know the slave's version (but we always recommended to users to have slave at least as new as master). As agreed with support, I have asked for an alert to be put into the MySQL Network Monitoring and Advisory Service. 3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets the changes from the main 5.1. BitKeeper/deleted/.del-rpl_insert_delayed.result: Delete: mysql-test/r/rpl_insert_delayed.result mysql-test/extra/rpl_tests/rpl_insert_delayed.test: tests for BUG#25507 (lauch many concurrent INSERT DELAYED into an auto_inc column and see if they cause duplicates) and BUG#26116 (see if one error at first row on master makes the slave's data incorrect). It is then incorporated into a statement-based and mixed binlogging test, and into a row-based test. It is in fact mysql-test/t/rpl_insert_delayed.test from 5.0, renamed and extended to test BUG#25507. mysql-test/extra/rpl_tests/rpl_insert_id.test: manual merge of test for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" from 5.0 mysql-test/r/rpl_insert_id.result: result update (it automerged from 5.0, contrary to the test file) mysql-test/r/rpl_known_bugs_detection.result: result update (binlog event sizes differ from 5.0) mysql-test/t/disabled.def: rpl_insert_id tests statement-based replication of INSERT ON DUPLICATE KEY UPDATE. This type of INSERT had BUG#24432, which is fixed in 5.1.16; we made the slave detect if it is connected to a <5.1.16 master and if so refuse to replicate. The problem is that this 5.1-rpl tree, even though it will produce the 5.1.16 release, still has a 5.1.15 version in configure.in. Thus rpl_insert_id fails. So I disable it. As soon as the 5.1-rpl tree gets the changesets from the main 5.1, its version will change to 5.1.16 and so I'll be able to re-enable the test. mysql-test/t/rpl_known_bugs_detection.test: only in statement-based; row-based has no bug so test would fail. sql/slave.cc: slave_print_msg(ERROR_LEVEL) calls my_error(ER_UNKNOWN_ERROR); so, for our my_printf_error(), which has a nicer message than this my_error(), to have any effect, it must be called before slave_print_msg() sql/sql_insert.cc: manual merge from 5.0 of a piece of the fixes for BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values" BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks". The other pieces (e.g. log_event.cc) automerged from 5.0. mysql-test/r/rpl_row_insert_delayed.result: result mysql-test/r/rpl_stm_insert_delayed.result: result. Note how "mixed" and "statement" insert different data in the table. mysql-test/t/rpl_row_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in row-based mode mysql-test/t/rpl_stm_insert_delayed.test: wrapper to test INSERT DELAYED binlogging in statement-based and mixed mode
2007-02-15 20:28:58 +01:00
USE test;
DROP SCHEMA mysqlslap;
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
sync_slave_with_master;
use test;
Fix for BUG#25507 "multi-row insert delayed + auto increment causes duplicate key entries on slave" (two concurrrent connections doing multi-row INSERT DELAYED to insert into an auto_increment column, caused replication slave to stop with "duplicate key error" (and binlog was wrong)), and BUG#26116 "If multi-row INSERT DELAYED has errors, statement-based binlogging breaks" (the binlog was not accounting for all rows inserted, or slave could stop). The fix is that: if (statement-based) binlogging is on, a multi-row INSERT DELAYED is silently converted to a non-delayed INSERT. Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap), so it is tested only in the changeset for 5.1. However, BUG#26116 is tested here, and the fix for BUG#25507 is the same code change. mysql-test/r/innodb-replace.result: result update mysql-test/t/innodb-replace.test: now that multi-row delayed inserts are converted to normal inserts if the statement-based binlog is enabled, no error is issued even if this engine does not support INSERT DELAYED, as the insert does not go through the INSERT DELAYED code. To preserve the goal of this test, we change the statements to single- row inserts. sql/sql_insert.cc: A multi-row INSERT DELAYED cannot be recorded to a statement-based binlog in a way that describes the insertions actually done; in that case we fallback to a non-delayed INSERT. mysql-test/r/rpl_insert_delayed.result: result. Master and slave match. mysql-test/t/rpl_insert_delayed.test: Test for BUG#26116 (see if one error at first row on master makes the slave's data incorrect, see if one error at second row on master makes slave stop).
2007-02-15 15:39:03 +01:00
connection master;
#
# Bug #29571: INSERT DELAYED IGNORE written to binary log on the master but
# on the slave
#
if (`SELECT @@global.binlog_format != 'ROW'`)
{
#flush the logs before the test
connection slave;
FLUSH LOGS;
connection master;
FLUSH LOGS;
}
CREATE TABLE t1(a int, UNIQUE(a));
INSERT DELAYED IGNORE INTO t1 VALUES(1);
INSERT DELAYED IGNORE INTO t1 VALUES(1);
flush table t1; # to wait for INSERT DELAYED to be done
if (`SELECT @@global.binlog_format != 'ROW'`)
{
#must show two INSERT DELAYED
--replace_column 1 x 2 x 3 x 4 x 5 x
show binlog events in 'master-bin.000002' LIMIT 2,2;
}
select * from t1;
sync_slave_with_master;
echo On slave;
if (`SELECT @@global.binlog_format != 'ROW'`)
{
#must show two INSERT DELAYED
--replace_column 1 x 2 x 3 x 4 x 5 x
show binlog events in 'slave-bin.000002' LIMIT 2,2;
}
select * from t1;
# clean up
connection master;
drop table t1;
sync_slave_with_master;
if (`SELECT @@global.binlog_format != 'ROW'`)
{
#flush the logs after the test
FLUSH LOGS;
connection master;
FLUSH LOGS;
}
connection master;
--echo End of 5.0 tests