| Bug #56662 | Assertion failed: next_insert_id == 0, file .\handler.cc | ||
|---|---|---|---|
| Submitted: | 8 Sep 2010 18:20 | Modified: | 4 Jan 2011 5:16 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Row Based Replication ( RBR ) | Severity: | S1 (Critical) |
| Version: | 5.1.50-debug, 5.1.51-debug | OS: | Any |
| Assigned to: | Daogang Qu | CPU Architecture: | Any |
[8 Sep 2010 18:20]
Shane Bester
[9 Sep 2010 7:00]
MySQL Verification Team
must be imported to master using "source bug56662.sql". ignore any errors.... watch slave crash
Attachment: bug56662.sql (application/octet-stream, text), 227.83 KiB.
[9 Sep 2010 7:02]
MySQL Verification Team
debug binary asserts. release binary has error in sql thread: 100909 9:02:30 [ERROR] Slave SQL: Could not execute Write_rows event on table test.t2; Duplicate entry '658' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log xp64-bin.000006, end_log_pos 58067, Error_code: 1062
[10 Sep 2010 22:18]
Sveta Smirnova
Thank you for the report. Verified as described. next-mr fails with "100911 1:18:12 [Warning] Slave: Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT. Error_code: 1666"
[21 Sep 2010 7:02]
Daogang Qu
Hi Shane Bester, When running bug56662.sql on master, how to ignore the following kind of errors?: 1. mysqltest: At line 343: query 'insert into t2(id,data) values (abs(-29457)%25,abs(16111)%25) on duplicate key update id=values(id),data=values(data)' failed: 1062: Duplicate entry '11' for key 'data' Their are about thirty similar errors, ignore them by Adding 'IGNORE' keyword for related INSERT STATEMENT? 2. mysqltest: At line 355: query 'start transaction' failed: 1399: XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state Is it OK to remove the statement? The bug is masked by lots of unusable statements in bug56662.sql file. Could you Please generate a simple test case for reproducing the bug?
[21 Sep 2010 7:10]
MySQL Verification Team
hi again! Ignore previous comment :) must be done using "source bug56662.sql" mysql client command. this is because some of the commands cause connection to be cut after committing and auto-reconnect is needed!
[21 Sep 2010 10:39]
Daogang Qu
Hi Shane Bester, I test it according to above comment. But I still just can get two kinds of errors as following: 1. ERROR 1062 (23000): Duplicate entry '2' for key 'data' ERROR 1062 (23000): Duplicate entry '14' for key 'data' ERROR 1062 (23000): Duplicate entry '7' for key 'data' Query OK, 0 rows affected (0.00 sec) 2. ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the PREPARED state ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the PREPARED state Query OK, 2 rows affected (0.00 sec) Did not get the reported bugs.
[28 Sep 2010 8:48]
Daogang Qu
Hi Shane Bester, The reported problem can not reproduced on mysql-5.1.50-enterprise-gpl-advanced-debug according to your test method too. Is it sporadic?
[28 Oct 2010 2:24]
Daogang Qu
The bug can not be reproduced base on the Version: '5.1.50-enterprise-gpl-advanced-debug'.
[29 Oct 2010 5:52]
MySQL Verification Team
still repeatable on 5.1.51... Master is started like this: ----------------------------- mysqld-debug --no-defaults --console --skip-gr --skip-na --log-bin --server-id=1 --port=3306 --tmpdir=. --socket=sock --binlog-format=row Slave is started like this: ---------------------------- mysqld-debug --no-defaults --console --skip-gr --skip-na --server-id=2 --port=3308 --tmpdir=. --socket=sock On slave: ------------- change master to master_host='127.0.0.1', master_port=3306, master_user='root', master_password=''; start slave; On Master: ------------- mysql -uroot test --no-beep source bug56662.sql *slave crashes* Sorry, but errors are needed for the testcase. This is why "source" command must be used. Assertion failed: next_insert_id == 0, file .\handler.cc, line 4611 mysqld-debug.exe!my_sigabrt_handler()[mysqld.cc:2086] mysqld-debug.exe!raise()[winsig.c:590] mysqld-debug.exe!abort()[abort.c:71] mysqld-debug.exe!_wassert()[assert.c:212] mysqld-debug.exe!handler::ha_external_lock()[handler.cc:4611] mysqld-debug.exe!unlock_external()[lock.cc:786] mysqld-debug.exe!mysql_unlock_tables()[lock.cc:391] mysqld-debug.exe!close_thread_tables()[sql_base.cc:1346] mysqld-debug.exe!Relay_log_info::cleanup_context()[rpl_rli.cc:1210] mysqld-debug.exe!rows_event_stmt_cleanup()[log_event.cc:7765] mysqld-debug.exe!Rows_log_event::do_apply_event()[log_event.cc:7684] mysqld-debug.exe!Log_event::apply_event()[log_event.h:1067] mysqld-debug.exe!apply_event_and_update_pos()[slave.cc:2154] mysqld-debug.exe!exec_relay_log_event()[slave.cc:2293] mysqld-debug.exe!handle_slave_sql()[slave.cc:3077] mysqld-debug.exe!pthread_start()[my_winthread.c:85] mysqld-debug.exe!_callthreadstart()[thread.c:293] mysqld-debug.exe!_threadstart()[thread.c:277] kernel32.dll!FlsSetValue()
[1 Nov 2010 8:28]
Daogang Qu
According to above way, I failed to start up the second server with error. Could you double check its options? But I can successfully start up the master servers as following steps: 1. Using manual gdb perl mysql-test-run.pl --manual-gdb --start rpl_view 2. Start deamon for master server ./mysqld-debug --defaults-group-suffix=.1 --defaults-file=../mysql-test/var/my.cnf --consol 3. Start deamon for slave server ./mysqld-debug --defaults-group-suffix=.2 --defaults-file=../mysql-test/var/my.cnf --consol 4. Connect to master sever ./mysql -u root --host localhost --port 13000 5. Connect to slave server ./mysql -u root --host localhost --port 13001 6. On slave: ------------- change master to master_host='127.0.0.1', master_port=13000, master_user='root', master_password=''; start slave; 7. On master: --------------- source bug56662.sql Could you please try the above steps for checking if it can reproduce the bug too? But I can't reproduce it on 5.1.50 version. I will try it on 5.1.50 version later.
[1 Nov 2010 8:30]
Daogang Qu
s/ try it on 5.1.50 / try it on 5.1.51
[1 Nov 2010 9:51]
MySQL Verification Team
Daogang, you need --binlog-format=row
[25 Nov 2010 10:25]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/125001 3518 Dao-Gang.Qu@sun.com 2010-11-25 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc In RBR, sometimes the new value of next_insert_id will be generated for current row when updating the auto_increment field of a table on slave side. Which causes the error. This is a incorrect behavior. After the patch, we never generate a new value for next_insert_id for current row when updating the auto_increment field of a table on slave side in RBR. @ mysql-test/suite/rpl/r/rpl_assert.result Test result for bug#56662 @ mysql-test/suite/rpl/t/rpl_assert.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ sql/handler.cc Added code to not generate a new value for next_insert_id for current row on slave side in RBR.
[6 Dec 2010 5:43]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126100 3524 Dao-Gang.Qu@sun.com 2010-12-06 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc In RBR, sometimes the new value of next_insert_id will be generated for current row when updating the auto_increment field of a table on slave side. Which causes the error. This is a incorrect behavior. After the patch, we never generate a new value for next_insert_id for current row when updating the auto_increment field of a table on slave side in RBR. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode.
[8 Dec 2010 3:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126283 3524 Dao-Gang.Qu@sun.com 2010-12-08 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc In RBR, the zero will fill auto_increment field of a table if add 'MODE_NO_AUTO_VALUE_ON_ZERO' to current sql_mode, then reset the sql_mode without 'MODE_NO_AUTO_VALUE_ON_ZERO' in a transation. Just the last setting of the sql_mode will be binlogged for the transaction. On slave, the transaction will be executed under the sql_mode without 'MODE_NO_AUTO_VALUE_ON_ZERO'. So the rows event with the 'zero' as the the value of auto_increment field in the transaction will cause generation of auto_increment value when applying it. Which causes the error. In fact, we never need generate a new next_insert_id for rows event when applying it on slave. So don't allow generation of auto_increment value when applying rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to current sql_mode. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master. Because the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[10 Dec 2010 8:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126507 3524 Dao-Gang.Qu@sun.com 2010-12-10 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, you generate the next sequence number for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the next sequence number. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a next sequence number for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[13 Dec 2010 3:12]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126587 3524 Dao-Gang.Qu@sun.com 2010-12-13 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[17 Dec 2010 10:08]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127157 3527 Dao-Gang.Qu@sun.com 2010-12-17 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[17 Dec 2010 10:23]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127164 3209 Dao-Gang.Qu@sun.com 2010-12-17 [merge] Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[20 Dec 2010 6:12]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127268 3446 Dao-Gang.Qu@sun.com 2010-12-20 [merge] Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[21 Dec 2010 4:55]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127347 3530 Dao-Gang.Qu@sun.com 2010-12-21 Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[21 Dec 2010 5:08]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127348 3218 Dao-Gang.Qu@sun.com 2010-12-21 [merge] Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[21 Dec 2010 10:32]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127375 3219 Dao-Gang.Qu@sun.com 2010-12-21 [merge] Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[21 Dec 2010 10:47]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/127379 3458 Dao-Gang.Qu@sun.com 2010-12-21 [merge] Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. @ mysql-test/extra/rpl_tests/rpl_auto_increment.test Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. @ mysql-test/suite/rpl/r/rpl_auto_increment.result Test result for bug#56662. @ sql/log_event.cc Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. @ sql/rpl_record.cc Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
[22 Dec 2010 21:31]
Bugs System
Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101222212842-y0t3ibtd32wd9qaw) (version source revid:alexander.nozdrin@oracle.com-20101222212842-y0t3ibtd32wd9qaw) (merge vers: 5.6.1) (pib:24)
[29 Dec 2010 12:51]
Bugs System
Pushed into mysql-5.1 5.1.55 (revid:alexander.nozdrin@oracle.com-20101229113432-o0c3f1pqklek1txm) (version source revid:alexander.nozdrin@oracle.com-20101229113109-ft3q9tewyueopxgf) (merge vers: 5.1.55) (pib:24)
[29 Dec 2010 12:52]
Bugs System
Pushed into mysql-5.5 5.5.9 (revid:alexander.nozdrin@oracle.com-20101229113652-km2v993aurv7h79j) (version source revid:alexander.nozdrin@oracle.com-20101229113132-uonlbcc2uopff8yb) (merge vers: 5.5.9) (pib:24)
[4 Jan 2011 5:16]
Jon Stephens
Documented bugfix in the 5.1.55 aqnd 5.5.9 changelogs as follows:
By default, a value is generated for an AUTO_INCREMENT column by
inserting either NULL or 0 into it. Setting the
NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior
for 0, so that it occurs only when NULL is inserted.
This behavior is also followed on a replication slave (by the
slave SQL thread) when applying events that have been logged on
the master using the statement-based format. However, when
applying events that had been logged using the row-based format,
NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an
assertion.
To fix this issue, values for AUTO_INCREMENT columns are no
longer generated when applying events that have been logged
using the row-based row format, as this value is already
contained in the changes applied on the slave.
No changelog entry required for 5.6.1, as this issue has not appeared in any 5.6 release.
Closed.
