BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
mysql-test/include/show_binlog_events.inc:
add $binlog_start parameter to show binlog events from a given position
sql/slave.cc:
Add function to check for bug#33029
sql/slave.h:
Add function to check for bug#33029
sql/sql_class.cc:
if master has bug#33029, reset auto_inc_intervals_forced for sub statements
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
sql/sql_class.h:
Add member to save and restore auto_inc_intervals_forced
sql/structs.h:
add copy constructor and assignment operator for Discrete_intervals_list
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
mysql-test/std_data/bug33029-slave-relay-bin.000001:
relay logs from a buggy 5.0 master for test case of BUG#33029
mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test:
Test if the slave can process relay logs from a buggy master of BUG#33029
2008-03-14 04:35:41 +01:00
|
|
|
# $binlog_start can be set by caller or take a default value
|
2009-09-29 01:04:20 +02:00
|
|
|
# $binary_log_file the name of the log file show
|
|
|
|
|
# $binary_log_limit_row - sets the number of binlog rows to be returned
|
|
|
|
|
# $binary_log_limit_offset - sets the offset where to start returning events
|
|
|
|
|
|
|
|
|
|
let $show_binlog_events= show binlog events;
|
BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
mysql-test/include/show_binlog_events.inc:
add $binlog_start parameter to show binlog events from a given position
sql/slave.cc:
Add function to check for bug#33029
sql/slave.h:
Add function to check for bug#33029
sql/sql_class.cc:
if master has bug#33029, reset auto_inc_intervals_forced for sub statements
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
sql/sql_class.h:
Add member to save and restore auto_inc_intervals_forced
sql/structs.h:
add copy constructor and assignment operator for Discrete_intervals_list
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
mysql-test/std_data/bug33029-slave-relay-bin.000001:
relay logs from a buggy 5.0 master for test case of BUG#33029
mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test:
Test if the slave can process relay logs from a buggy master of BUG#33029
2008-03-14 04:35:41 +01:00
|
|
|
|
|
|
|
|
if (!$binlog_start)
|
|
|
|
|
{
|
2009-09-29 01:04:20 +02:00
|
|
|
# defaults to chop the first event in the binary log
|
BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
mysql-test/include/show_binlog_events.inc:
add $binlog_start parameter to show binlog events from a given position
sql/slave.cc:
Add function to check for bug#33029
sql/slave.h:
Add function to check for bug#33029
sql/sql_class.cc:
if master has bug#33029, reset auto_inc_intervals_forced for sub statements
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
sql/sql_class.h:
Add member to save and restore auto_inc_intervals_forced
sql/structs.h:
add copy constructor and assignment operator for Discrete_intervals_list
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
mysql-test/std_data/bug33029-slave-relay-bin.000001:
relay logs from a buggy 5.0 master for test case of BUG#33029
mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test:
Test if the slave can process relay logs from a buggy master of BUG#33029
2008-03-14 04:35:41 +01:00
|
|
|
let $binlog_start=106;
|
|
|
|
|
}
|
2009-09-29 01:04:20 +02:00
|
|
|
|
|
|
|
|
if (!`SELECT '$binary_log_file' = ''`)
|
|
|
|
|
{
|
|
|
|
|
let $show_binlog_events= $show_binlog_events in '$binary_log_file';
|
|
|
|
|
}
|
|
|
|
|
let $show_binlog_events= $show_binlog_events from $binlog_start;
|
|
|
|
|
|
|
|
|
|
if ($binary_log_limit_row)
|
|
|
|
|
{
|
|
|
|
|
let $limit= limit;
|
|
|
|
|
if ($binary_log_limit_offset)
|
|
|
|
|
{
|
|
|
|
|
let $limit= $limit $binary_log_limit_offset, ;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let $limit= $limit $binary_log_limit_row;
|
|
|
|
|
let $show_binlog_events= $show_binlog_events $limit;
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-18 13:34:19 +02:00
|
|
|
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR $binlog_start <binlog_start>
|
2007-04-18 23:08:56 +02:00
|
|
|
--replace_column 2 # 4 # 5 #
|
2008-07-18 13:34:19 +02:00
|
|
|
--replace_regex /\/\* xid=.* \*\//\/* XID *\// /table_id: [0-9]+/table_id: #/ /file_id=[0-9]+/file_id=#/ /block_len=[0-9]+/block_len=#/
|
2009-09-29 01:04:20 +02:00
|
|
|
--eval $show_binlog_events
|