Fix for 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 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
master to a fixed (5.0.36) 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 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'll also ask for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
mysql-test/r/rpl_insert_id.result:
results to check the bugfix; without the bugfix, you would see, in
master and slave:
"3,2" instead of "2,2" for the INSERT VALUES testcase,
"11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
mysql-test/t/rpl_insert_id.test:
testing that BUG#24432 is fixed
sql/log_event.cc:
A trick to force the master to pretend it is old and features BUG#24432.
To do fast lookups in the list of known bugs by version, we compute
the 3 X.Y.Z numbers from the master's version string and cache that
into a new member Format_description_log_event::server_version_split.
We do this computation in the event's two constructors.
A simple prevention against buffer overrun when reading the master's
version from a binlog event (assume the event is corrupted on disk,
and so the version string on disk is longer than ST_SERVER_VER_LEN
(50), then we would not get a closing 0 at the end of the class member.
sql/log_event.h:
new member to hold the "split server version" (3 numbers X.Y.Z),
and a method to compute this from the version string.
sql/slave.cc:
a function which tells, based on master's version (as found
in the Format_description event in the relay log being executed),
if master can have a certain bug. This function uses a list of
bug_id / first_version_with_bug / first_version_with_fix.
If the test is positive, a short error message is put into SHOW SLAVE
STATUS, and a verbose message is put into the slave's error log.
The caller is expected to stop the slave in this case.
sql/slave.h:
new function to test if the replication master has a bug
sql/sql_insert.cc:
Fix for BUG#24432:t he reason was a misplaced restore_auto_increment()
(misplaced when fixing BUG#20188). Indeed, when updating the row,
it is clear that the autogenerated auto_increment value will not be
used for this row (and if by "chance" the autoinc value present
in the updated row is >= to the not used autogenerated value,
adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
We also add code for a fixed slave to detect that it is connected to
a buggy master (in which case it cannot replicate so stops).
mysql-test/r/rpl_known_bugs_detection.result:
see that SHOW SLAVE STATUS prints information that slave found a bug
in master, and does not execute the dangerous event (table stays
empty).
mysql-test/t/rpl_known_bugs_detection-master.opt:
pass debug symbol to make the master pretend it has BUG#24432
mysql-test/t/rpl_known_bugs_detection.test:
new test to see if bug detection by slave works
2007-02-08 15:53:14 +01:00
|
|
|
# Test to see if slave can detect certain known bugs present
|
|
|
|
# on the master, and appropriately decides to stop
|
|
|
|
# (assuming the bug is fixed in the slave, slave cannot of course
|
|
|
|
# imitate the bug, so it has to stop).
|
|
|
|
|
|
|
|
source include/have_debug.inc;
|
|
|
|
source include/master-slave.inc;
|
|
|
|
|
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
|
|
|
# Currently only statement-based-specific bugs are here
|
|
|
|
-- source include/have_binlog_format_mixed_or_statement.inc
|
|
|
|
|
Fix for 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 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
master to a fixed (5.0.36) 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 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'll also ask for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
mysql-test/r/rpl_insert_id.result:
results to check the bugfix; without the bugfix, you would see, in
master and slave:
"3,2" instead of "2,2" for the INSERT VALUES testcase,
"11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
mysql-test/t/rpl_insert_id.test:
testing that BUG#24432 is fixed
sql/log_event.cc:
A trick to force the master to pretend it is old and features BUG#24432.
To do fast lookups in the list of known bugs by version, we compute
the 3 X.Y.Z numbers from the master's version string and cache that
into a new member Format_description_log_event::server_version_split.
We do this computation in the event's two constructors.
A simple prevention against buffer overrun when reading the master's
version from a binlog event (assume the event is corrupted on disk,
and so the version string on disk is longer than ST_SERVER_VER_LEN
(50), then we would not get a closing 0 at the end of the class member.
sql/log_event.h:
new member to hold the "split server version" (3 numbers X.Y.Z),
and a method to compute this from the version string.
sql/slave.cc:
a function which tells, based on master's version (as found
in the Format_description event in the relay log being executed),
if master can have a certain bug. This function uses a list of
bug_id / first_version_with_bug / first_version_with_fix.
If the test is positive, a short error message is put into SHOW SLAVE
STATUS, and a verbose message is put into the slave's error log.
The caller is expected to stop the slave in this case.
sql/slave.h:
new function to test if the replication master has a bug
sql/sql_insert.cc:
Fix for BUG#24432:t he reason was a misplaced restore_auto_increment()
(misplaced when fixing BUG#20188). Indeed, when updating the row,
it is clear that the autogenerated auto_increment value will not be
used for this row (and if by "chance" the autoinc value present
in the updated row is >= to the not used autogenerated value,
adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
We also add code for a fixed slave to detect that it is connected to
a buggy master (in which case it cannot replicate so stops).
mysql-test/r/rpl_known_bugs_detection.result:
see that SHOW SLAVE STATUS prints information that slave found a bug
in master, and does not execute the dangerous event (table stays
empty).
mysql-test/t/rpl_known_bugs_detection-master.opt:
pass debug symbol to make the master pretend it has BUG#24432
mysql-test/t/rpl_known_bugs_detection.test:
new test to see if bug detection by slave works
2007-02-08 15:53:14 +01:00
|
|
|
#
|
|
|
|
# This is to test that slave properly detects if
|
|
|
|
# master may suffer from:
|
|
|
|
# BUG#24432 "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values"
|
|
|
|
# (i.e. on master, INSERT ON DUPLICATE KEY UPDATE is used and manipulates
|
|
|
|
# an auto_increment column, and is binlogged statement-based).
|
|
|
|
#
|
|
|
|
|
|
|
|
# testcase with INSERT VALUES
|
|
|
|
CREATE TABLE t1 (a INT NOT NULL PRIMARY KEY AUTO_INCREMENT, b INT,
|
|
|
|
UNIQUE(b));
|
|
|
|
sync_slave_with_master;
|
|
|
|
connection master;
|
|
|
|
INSERT INTO t1(b) VALUES(1),(1),(2) ON DUPLICATE KEY UPDATE t1.b=10;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
connection slave;
|
2007-06-13 19:52:42 +02:00
|
|
|
--source include/wait_for_slave_sql_to_stop.inc
|
Fix for 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 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
master to a fixed (5.0.36) 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 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'll also ask for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
mysql-test/r/rpl_insert_id.result:
results to check the bugfix; without the bugfix, you would see, in
master and slave:
"3,2" instead of "2,2" for the INSERT VALUES testcase,
"11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
mysql-test/t/rpl_insert_id.test:
testing that BUG#24432 is fixed
sql/log_event.cc:
A trick to force the master to pretend it is old and features BUG#24432.
To do fast lookups in the list of known bugs by version, we compute
the 3 X.Y.Z numbers from the master's version string and cache that
into a new member Format_description_log_event::server_version_split.
We do this computation in the event's two constructors.
A simple prevention against buffer overrun when reading the master's
version from a binlog event (assume the event is corrupted on disk,
and so the version string on disk is longer than ST_SERVER_VER_LEN
(50), then we would not get a closing 0 at the end of the class member.
sql/log_event.h:
new member to hold the "split server version" (3 numbers X.Y.Z),
and a method to compute this from the version string.
sql/slave.cc:
a function which tells, based on master's version (as found
in the Format_description event in the relay log being executed),
if master can have a certain bug. This function uses a list of
bug_id / first_version_with_bug / first_version_with_fix.
If the test is positive, a short error message is put into SHOW SLAVE
STATUS, and a verbose message is put into the slave's error log.
The caller is expected to stop the slave in this case.
sql/slave.h:
new function to test if the replication master has a bug
sql/sql_insert.cc:
Fix for BUG#24432:t he reason was a misplaced restore_auto_increment()
(misplaced when fixing BUG#20188). Indeed, when updating the row,
it is clear that the autogenerated auto_increment value will not be
used for this row (and if by "chance" the autoinc value present
in the updated row is >= to the not used autogenerated value,
adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
We also add code for a fixed slave to detect that it is connected to
a buggy master (in which case it cannot replicate so stops).
mysql-test/r/rpl_known_bugs_detection.result:
see that SHOW SLAVE STATUS prints information that slave found a bug
in master, and does not execute the dangerous event (table stays
empty).
mysql-test/t/rpl_known_bugs_detection-master.opt:
pass debug symbol to make the master pretend it has BUG#24432
mysql-test/t/rpl_known_bugs_detection.test:
new test to see if bug detection by slave works
2007-02-08 15:53:14 +01:00
|
|
|
# show the error message
|
|
|
|
--replace_column 1 # 4 # 7 # 8 # 9 # 23 # 33 #
|
|
|
|
--query_vertical show slave status;
|
|
|
|
# show that it was not replicated
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
|
|
|
# restart replication for the next testcase
|
|
|
|
stop slave;
|
|
|
|
reset slave;
|
|
|
|
connection master;
|
|
|
|
reset master;
|
|
|
|
drop table t1;
|
|
|
|
connection slave;
|
|
|
|
start slave;
|
|
|
|
|
|
|
|
# testcase with INSERT SELECT
|
|
|
|
connection master;
|
|
|
|
CREATE TABLE t1 (
|
|
|
|
id bigint(20) unsigned NOT NULL auto_increment,
|
|
|
|
field_1 int(10) unsigned NOT NULL,
|
|
|
|
field_2 varchar(255) NOT NULL,
|
|
|
|
field_3 varchar(255) NOT NULL,
|
|
|
|
PRIMARY KEY (id),
|
|
|
|
UNIQUE KEY field_1 (field_1, field_2)
|
|
|
|
);
|
|
|
|
CREATE TABLE t2 (
|
|
|
|
field_a int(10) unsigned NOT NULL,
|
|
|
|
field_b varchar(255) NOT NULL,
|
|
|
|
field_c varchar(255) NOT NULL
|
|
|
|
);
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (1, 'a', '1a');
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (2, 'b', '2b');
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (3, 'c', '3c');
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (4, 'd', '4d');
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (5, 'e', '5e');
|
|
|
|
sync_slave_with_master;
|
|
|
|
connection master;
|
|
|
|
# Updating table t1 based on values from table t2
|
|
|
|
INSERT INTO t1 (field_1, field_2, field_3)
|
|
|
|
SELECT t2.field_a, t2.field_b, t2.field_c
|
|
|
|
FROM t2
|
|
|
|
ON DUPLICATE KEY UPDATE
|
|
|
|
t1.field_3 = t2.field_c;
|
|
|
|
# Inserting new record into t2
|
|
|
|
INSERT INTO t2 (field_a, field_b, field_c) VALUES (6, 'f', '6f');
|
|
|
|
# Updating t1 again
|
|
|
|
INSERT INTO t1 (field_1, field_2, field_3)
|
|
|
|
SELECT t2.field_a, t2.field_b, t2.field_c
|
|
|
|
FROM t2
|
|
|
|
ON DUPLICATE KEY UPDATE
|
|
|
|
t1.field_3 = t2.field_c;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
connection slave;
|
2007-06-13 17:43:31 +02:00
|
|
|
--source include/wait_for_slave_sql_to_stop.inc
|
Fix for 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 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
master to a fixed (5.0.36) 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 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'll also ask for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
mysql-test/r/rpl_insert_id.result:
results to check the bugfix; without the bugfix, you would see, in
master and slave:
"3,2" instead of "2,2" for the INSERT VALUES testcase,
"11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
mysql-test/t/rpl_insert_id.test:
testing that BUG#24432 is fixed
sql/log_event.cc:
A trick to force the master to pretend it is old and features BUG#24432.
To do fast lookups in the list of known bugs by version, we compute
the 3 X.Y.Z numbers from the master's version string and cache that
into a new member Format_description_log_event::server_version_split.
We do this computation in the event's two constructors.
A simple prevention against buffer overrun when reading the master's
version from a binlog event (assume the event is corrupted on disk,
and so the version string on disk is longer than ST_SERVER_VER_LEN
(50), then we would not get a closing 0 at the end of the class member.
sql/log_event.h:
new member to hold the "split server version" (3 numbers X.Y.Z),
and a method to compute this from the version string.
sql/slave.cc:
a function which tells, based on master's version (as found
in the Format_description event in the relay log being executed),
if master can have a certain bug. This function uses a list of
bug_id / first_version_with_bug / first_version_with_fix.
If the test is positive, a short error message is put into SHOW SLAVE
STATUS, and a verbose message is put into the slave's error log.
The caller is expected to stop the slave in this case.
sql/slave.h:
new function to test if the replication master has a bug
sql/sql_insert.cc:
Fix for BUG#24432:t he reason was a misplaced restore_auto_increment()
(misplaced when fixing BUG#20188). Indeed, when updating the row,
it is clear that the autogenerated auto_increment value will not be
used for this row (and if by "chance" the autoinc value present
in the updated row is >= to the not used autogenerated value,
adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
We also add code for a fixed slave to detect that it is connected to
a buggy master (in which case it cannot replicate so stops).
mysql-test/r/rpl_known_bugs_detection.result:
see that SHOW SLAVE STATUS prints information that slave found a bug
in master, and does not execute the dangerous event (table stays
empty).
mysql-test/t/rpl_known_bugs_detection-master.opt:
pass debug symbol to make the master pretend it has BUG#24432
mysql-test/t/rpl_known_bugs_detection.test:
new test to see if bug detection by slave works
2007-02-08 15:53:14 +01:00
|
|
|
# show the error message
|
|
|
|
--replace_column 1 # 4 # 7 # 8 # 9 # 23 # 33 #
|
|
|
|
--query_vertical show slave status;
|
|
|
|
# show that it was not replicated
|
|
|
|
SELECT * FROM t1;
|
|
|
|
connection master;
|
|
|
|
drop table t1, t2;
|
|
|
|
connection slave;
|
|
|
|
drop table t1, t2;
|
|
|
|
|
|
|
|
# End of 5.0 tests
|