| Bug #25688 | RBR: circular replication may cause STMT_END_F flags to be skipped | ||
|---|---|---|---|
| Submitted: | 18 Jan 2007 7:52 | Modified: | 24 Apr 2007 4:34 |
| Reporter: | Tomas Ulin | ||
| Status: | Closed | ||
| Category: | Server: ClusterRep | Severity: | S2 (Serious) |
| Version: | 5.1 | OS: | Any |
| Assigned to: | Mats Kindahl | Target Version: | |
[28 Mar 2007 15:19]
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/23144 ChangeSet@1.2479, 2007-03-28 15:19:18+02:00, mats@romeo.(none) +2 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway).
[29 Mar 2007 8:47]
Andrei Elkin
Bug #25770 must be a dup of this one.
[31 Mar 2007 18: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/23472 ChangeSet@1.2479, 2007-03-30 16:01:47+02:00, mats@romeo.(none) +2 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway).
[4 Apr 2007 15:01]
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/23782 ChangeSet@1.2479, 2007-04-04 15:00:47+02:00, mats@romeo.(none) +4 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway).
[10 Apr 2007 15:15]
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/24163 ChangeSet@1.2547, 2007-04-10 15:15:06+02:00, mats@romeo.(none) +2 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): Adding test case.
[10 Apr 2007 15:19]
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/24165 ChangeSet@1.2546, 2007-04-10 15:18:54+02:00, mats@romeo.(none) +6 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway). Adding test case.
[10 Apr 2007 21:44]
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/24213 ChangeSet@1.2547, 2007-04-10 21:43:42+02:00, mats@romeo.(none) +2 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): Fixing logic to detect if inside a group. If a rotate event occured when an initial prefix of events for a statement, but for which the table did contain a key, last_event_start_time is set to zero, causing rotate to end the group but without unlocking any tables. This left a lock hanging around, which subsequently triggered an assertion when a second attempt was made to lock the same sequence of tables.
[11 Apr 2007 14:44]
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/24276 ChangeSet@1.2546, 2007-04-11 14:42:57+02:00, mats@romeo.(none) +19 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway). Adding test case. Fixing logic to detect if inside a group. If a rotate event occured when an initial prefix of events for a statement, but for which the table did contain a key, last_event_start_time is set to zero, causing rotate to end the group but without unlocking any tables. This left a lock hanging around, which subsequently triggered an assertion when a second attempt was made to lock the same sequence of tables. In order to solve the above problem, a new flag was added to the relay log info structure that is used to indicate that the replication thread is currently executing a statement. Using this flag, the replication thread is in a group if it is either in a statement or inside a trans- action. The patch also eliminates some gratuitous header file inclusions that were not needed (and caused compile errors) and replaced them with forward definitions.
[12 Apr 2007 8:51]
Rafal Somla
Patch approved.
[12 Apr 2007 8:57]
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/24361 ChangeSet@1.2547, 2007-04-12 08:56:07+02:00, mats@romeo.(none) +1 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): Documentation fixes.
[12 Apr 2007 8:58]
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/24362 ChangeSet@1.2546, 2007-04-12 08:58:04+02:00, mats@romeo.(none) +19 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): By moving statement end actions from Rows_log_event::do_apply_event() to Rows_log_event::do_update_pos() they will always be executed, even if Rows_log_event::do_apply_event() is skipped because the event originated at the same server. This because Rows_log_event::do_update_pos() is always executed (unless Rows_log_event::do_apply_event() failed with an error, in which case the slave stops with an error anyway). Adding test case. Fixing logic to detect if inside a group. If a rotate event occured when an initial prefix of events for a statement, but for which the table did contain a key, last_event_start_time is set to zero, causing rotate to end the group but without unlocking any tables. This left a lock hanging around, which subsequently triggered an assertion when a second attempt was made to lock the same sequence of tables. In order to solve the above problem, a new flag was added to the relay log info structure that is used to indicate that the replication thread is currently executing a statement. Using this flag, the replication thread is in a group if it is either in a statement or inside a trans- action. The patch also eliminates some gratuitous header file inclusions that were not needed (and caused compile errors) and replaced them with forward definitions.
[12 Apr 2007 10:06]
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/24365 ChangeSet@1.2553, 2007-04-12 10:05:55+02:00, mats@romeo.(none) +1 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): Post-merge changes.
[12 Apr 2007 14:17]
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/24378 ChangeSet@1.2554, 2007-04-12 14:14:50+02:00, mats@romeo.(none) +2 -0 BUG#25688 (RBR: circular replication may cause STMT_END_F flags to be skipped): Fixing test since a replace assumed that we were on slave when we were on master.
[20 Apr 2007 19:16]
Bugs System
Pushed into 5.1.18-beta
[24 Apr 2007 4:34]
Jon Stephens
Thank you for your bug report. This issue has been committed to our source repository of
that product and will be incorporated into the next release.
If necessary, you can access the source repository and build the latest available
version, including the bug fix. More information about accessing the source trees is
available at
http://dev.mysql.com/doc/en/installing-source.html
Documented bugfix in 5.1.18 changelog.
Documented ramifications for cluster replication in Cluster Replication Known Issues
section of 5.1 Manual following IRC/email discussion with Tomas.
See http://lists.mysql.com/commits/25213 for docs changes.
Description: | slave-bin.000001 | 514 | Query | 2 | 578 | BEGIN | slave-bin.000001 | 578 | Table_map | 2 | 40 | table_id: 19 (test.t1) | | slave-bin.000001 | 618 | Table_map | 2 | 95 | table_id: 17 (mysql.ndb_apply_status) | | slave-bin.000001 | 673 | Write_rows | 2 | 137 | table_id: 17 | | slave-bin.000001 | 715 | Write_rows | 2 | 175 | table_id: 19 flags: STMT_END_F | | slave-bin.000001 | 753 | Query | 2 | 818 | COMMIT | now, the event with table_id 19 gets skipped, because it is circularly replicated... and becaues the STMT_END_F flag is piggybacked on this event the tables locked at the beginning of the transaction are not unlocked... causing a crash (dbug assert) later... How to repeat: see above