BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.0 fixed it not to generate the erroneous Intvar
event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
value when executing functions/triggers if it is replicating from
a master of buggy versions.
2008-03-14 03:03:01 +01:00
|
|
|
# BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
|
|
|
|
# using a trig in SP
|
|
|
|
|
|
|
|
# For all 5.0 up to 5.0.58 exclusive, and 5.1 up to 5.1.12 exclusive,
|
|
|
|
# if one statement in a SP generated AUTO_INCREMENT value by the top
|
|
|
|
# statement, all statements after it would be considered generated
|
|
|
|
# AUTO_INCREMENT value by the top statement, and a erroneous INSERT_ID
|
|
|
|
# value might be associated with these statement, which could cause
|
|
|
|
# duplicate entry error and stop the slave.
|
|
|
|
|
|
|
|
source include/master-slave.inc;
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1, t2;
|
|
|
|
DROP PROCEDURE IF EXISTS p1;
|
|
|
|
DROP PROCEDURE IF EXISTS p2;
|
|
|
|
DROP TRIGGER IF EXISTS tr1;
|
|
|
|
DROP FUNCTION IF EXISTS f1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (id INT AUTO_INCREMENT PRIMARY KEY);
|
|
|
|
CREATE TABLE t2 (id INT AUTO_INCREMENT PRIMARY KEY);
|
|
|
|
|
|
|
|
delimiter //;
|
|
|
|
|
|
|
|
CREATE PROCEDURE p1()
|
|
|
|
BEGIN
|
|
|
|
DECLARE ins_count INT DEFAULT 10;
|
|
|
|
|
|
|
|
WHILE ins_count > 0 DO
|
|
|
|
INSERT INTO t1 VALUES (NULL);
|
|
|
|
SET ins_count = ins_count - 1;
|
|
|
|
END WHILE;
|
|
|
|
|
|
|
|
DELETE FROM t1 WHERE id = 1;
|
|
|
|
DELETE FROM t1 WHERE id = 2;
|
|
|
|
DELETE FROM t2 WHERE id = 1;
|
|
|
|
DELETE FROM t2 WHERE id = 2;
|
|
|
|
END//
|
|
|
|
|
|
|
|
CREATE PROCEDURE p2()
|
|
|
|
BEGIN
|
|
|
|
INSERT INTO t1 VALUES (NULL);
|
|
|
|
DELETE FROM t1 WHERE id = f1(3);
|
|
|
|
DELETE FROM t1 WHERE id = f1(4);
|
|
|
|
DELETE FROM t2 WHERE id = 3;
|
|
|
|
DELETE FROM t2 WHERE id = 4;
|
|
|
|
END//
|
|
|
|
|
|
|
|
CREATE TRIGGER tr1 BEFORE DELETE
|
|
|
|
ON t1 FOR EACH ROW
|
|
|
|
BEGIN
|
|
|
|
INSERT INTO t2 VALUES (NULL);
|
|
|
|
END//
|
|
|
|
|
|
|
|
CREATE FUNCTION f1 (i int) RETURNS int
|
|
|
|
BEGIN
|
|
|
|
INSERT INTO t2 VALUES (NULL);
|
|
|
|
RETURN i;
|
|
|
|
END//
|
|
|
|
|
|
|
|
delimiter ;//
|
|
|
|
|
|
|
|
# the $binlog_start will be used by the show_binlog_events.inc, so
|
|
|
|
# that we can skip binlog events we don't care
|
|
|
|
let $binlog_start= query_get_value(SHOW MASTER STATUS, Position, 1);
|
|
|
|
CALL p1();
|
|
|
|
source include/show_binlog_events.inc;
|
|
|
|
|
|
|
|
echo # Result on master;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
SELECT * FROM t2;
|
|
|
|
|
|
|
|
sync_slave_with_master;
|
|
|
|
|
|
|
|
echo # Result on slave;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
SELECT * FROM t2;
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
|
|
|
DROP TRIGGER tr1;
|
|
|
|
|
|
|
|
# the $binlog_start will be used by the show_binlog_events.inc, so
|
|
|
|
# that we can skip binlog events we don't care
|
|
|
|
let $binlog_start= query_get_value(SHOW MASTER STATUS, Position, 1);
|
|
|
|
CALL p2();
|
|
|
|
source include/show_binlog_events.inc;
|
|
|
|
|
|
|
|
echo # Result on master;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
SELECT * FROM t2;
|
|
|
|
|
|
|
|
sync_slave_with_master;
|
|
|
|
|
|
|
|
echo # Result on slave;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
SELECT * FROM t2;
|
|
|
|
|
|
|
|
# clean up
|
|
|
|
connection master;
|
2008-03-27 06:42:34 +01:00
|
|
|
disable_warnings;
|
BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.0 fixed it not to generate the erroneous Intvar
event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
value when executing functions/triggers if it is replicating from
a master of buggy versions.
2008-03-14 03:03:01 +01:00
|
|
|
DROP TABLE IF EXISTS t1, t2;
|
|
|
|
DROP PROCEDURE IF EXISTS p1;
|
|
|
|
DROP PROCEDURE IF EXISTS p2;
|
|
|
|
DROP FUNCTION IF EXISTS f1;
|
|
|
|
DROP TRIGGER IF EXISTS tr1;
|
2008-03-27 06:42:34 +01:00
|
|
|
enable_warnings;
|
BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.0 fixed it not to generate the erroneous Intvar
event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
value when executing functions/triggers if it is replicating from
a master of buggy versions.
2008-03-14 03:03:01 +01:00
|
|
|
sync_slave_with_master;
|