Bug #45677 Slave stops with Duplicate entry for key PRIMARY when using trigger
The problem is that there is only one autoinc value associated with the query when binlogging. If more than one autoinc values are used in the query, the autoinc values after the first one can be inserted wrongly on slave. So these autoinc values can become inconsistent on master and slave. The problem is resolved by marking all the statements that invoke a trigger or call a function that updated autoinc fields as unsafe, and will switch to row-format in Mixed mode. Actually, the statement is safe if just one autoinc value is used in sub-statement, but it's impossible to check how many autoinc values are used in sub-statement.) mysql-test/suite/rpl/r/rpl_auto_increment_update_failure.result: Test result for bug#45677 mysql-test/suite/rpl/t/rpl_auto_increment_update_failure.test: Added test to verify the following two properties: P1) insert/update in an autoinc column causes statement to be logged in row format if binlog_format=mixed P2) if binlog_format=mixed, and a trigger or function contains two or more inserts/updates in a table that has an autoinc column, then the slave should not go out of sync, even if there are concurrent transactions. sql/sql_base.cc: Added function 'has_write_table_with_auto_increment' to check if one (or more) write tables have auto_increment columns. Removed function 'has_two_write_locked_tables_with_auto_increment', because the function is included in function 'has_write_table_with_auto_increment'.
Showing
Please register or sign in to comment