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.
2007-02-15 20:28:58 +01:00
|
|
|
# we run first in statement-based then in mixed binlogging
|
|
|
|
|
|
|
|
|
|
--source include/have_binlog_format_mixed_or_statement.inc
|
|
|
|
|
--source include/master-slave.inc
|
|
|
|
|
--source include/not_embedded.inc
|
|
|
|
|
--source include/not_windows.inc
|
|
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
set @old_global_binlog_format = @@global.binlog_format;
|
|
|
|
|
|
|
|
|
|
let $binlog_format_statement=1;
|
|
|
|
|
set @@global.binlog_format = statement;
|
|
|
|
|
--source extra/rpl_tests/rpl_insert_delayed.test
|
|
|
|
|
|
|
|
|
|
let $binlog_format_statement=0;
|
|
|
|
|
set @@global.binlog_format = mixed;
|
|
|
|
|
--source extra/rpl_tests/rpl_insert_delayed.test
|
|
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
set @@global.binlog_format = @old_global_binlog_format;
|