| Bug #25998 | problems about circle replication | ||
|---|---|---|---|
| Submitted: | 1 Feb 2007 4:06 | Modified: | 18 Jul 16:59 |
| Reporter: | mingfei hua | ||
| Status: | Patch queued | ||
| Category: | Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.0.27 | OS: | Linux (linux) |
| Assigned to: | Andrei Elkin | Target Version: | |
| Triage: | Triaged: D5 (Feature request) | ||
[5 Feb 2007 19:45]
Sveta Smirnova
Thank you for the report. Verified as described.
[4 Sep 2007 14:27]
Lars Thalmann
Duplicate of BUG#27808.
[28 Apr 13:14]
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/46108 ChangeSet@1.2634, 2008-04-28 14:11:47+03:00, aelkin@mysql1000.(none) +9 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of the circular multi-master replication after withdrawing one of the members events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been a part of the event flow termination. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case no withdrawing is necessary at all. In order to fix both artifacts it is enough to introduce a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the old MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. the old setup preserving by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. implementing a new status variable show status like "slave_replicate_ignore_server_id" f. Differently from --replicate-same-server-id handling, sql thread is not concerned with the ignored server id, because it's supposed that the relay log constists only of events that can not be unstoppable. IO thread takes care of an unstoppable event can not penetrate into the relay log. g. Rotate and FD events are still relay-logged. They can not circulate.
[28 Apr 14:10]
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/46111 ChangeSet@1.2634, 2008-04-28 15:08:14+03:00, aelkin@mysql1000.(none) +9 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of the circular multi-master replication after withdrawing one of the members events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been a part of the event flow termination. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case no withdrawing is necessary at all. In order to fix both artifacts it is enough to introduce a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the old MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. the old setup preserving by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. implementing a new status variable show status like "slave_replicate_ignore_server_id" f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server id, because it's supposed that the relay log constists only of events that can not be unstoppable. IO thread takes care of an unstoppable event can not penetrate into the relay log. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged. Their termination remains to be a duty of the current master.
[28 Apr 19:11]
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/46130 ChangeSet@1.2634, 2008-04-28 20:08:05+03:00, aelkin@mysql1000.(none) +8 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of the circular multi-master replication after withdrawing one of the members events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been a part of the event flow termination. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case no withdrawing is necessary at all. In order to fix both artifacts it is enough to introduce a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the old MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. the old setup preserving by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server id, because it's supposed that the relay log constists only of events that can not be unstoppable. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged. There is issue with their termination. Use cases for this feature can be found on the bug report page.
[29 Apr 12:00]
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/46178 ChangeSet@1.2634, 2008-04-29 12:58:22+03:00, aelkin@mysql1000.(none) +8 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of the same cluster and replicated to another member got accepted despite effects of the event had been propagated across the cluster via cluster communications. In order to fix both artifacts it is enough to introduce a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[29 Apr 12:02]
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/46179 ChangeSet@1.2634, 2008-04-29 13:00:20+03:00, aelkin@mysql1000.(none) +8 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of the same cluster and replicated to another member got accepted despite effects of the event had been propagated across the cluster via cluster communications. In order to fix both artifacts it is enough to introduce a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[8 May 19:52]
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/46529 ChangeSet@1.2634, 2008-05-08 20:51:00+03:00, aelkin@mysql1000.dsl.inet.fi +13 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of the same cluster and replicated to another member got accepted despite effects of the event had been propagated across the cluster via cluster communications. Both artifacts are fixable with introducing a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[8 May 20: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/46530 ChangeSet@1.2634, 2008-05-08 21:00:35+03:00, aelkin@mysql1000.dsl.inet.fi +13 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of the same cluster and replicated to another member got accepted despite effects of the event had been propagated across the cluster via cluster communications. Both artifacts are fixable with introducing a new option for CHANGE MASTER. MASTER_IGNORE_SERVER_ID= some_server_id can be repeated multiple times to list all the servers from which events would not be put into relay log and therefore would not be executed. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[22 May 17:16]
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/46956 ChangeSet@1.2634, 2008-05-22 18:15:48+03:00, aelkin@mysql1000.dsl.inet.fi +11 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of a cluster was replicated to another member, got accepted and executed. By that same time effects of the event had been already propagated across the cluster via the cluster communications. In order to avoid double-applying, a replication event generated by a co-member of the cluster should not be accepted. Both variations of the unstoppable replication event are fixable with introducing a new option for CHANGE MASTER: IGNORE_SERVER_ID= some_server_id The option can be repeated multiple times if there are more than one server to ignore events from. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing MASTER_IGNORE_SERVER_ID list by the following CHANGE MASTER ... MASTER_IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o MASTER_IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[22 May 19: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/46967 ChangeSet@1.2634, 2008-05-22 20:57:18+03:00, aelkin@mysql1000.dsl.inet.fi +11 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of a cluster was replicated to another member, got accepted and executed. By that same time effects of the event had been already propagated across the cluster via the cluster communications. In order to avoid double-applying, a replication event generated by a co-member of the cluster should not be accepted. Both variations of the unstoppable replication event are fixable with introducing a new option for CHANGE MASTER: IGNORE_SERVER_ID= some_server_id The option can be repeated multiple times if there are more than one server to ignore events from. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing IGNORE_SERVER_ID list by the following CHANGE MASTER ... IGNORE_SERVER_ID=; c. preserving the existing list by CHANGE MASTER w/o IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[30 May 15:59]
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/47258 ChangeSet@1.2634, 2008-05-30 16:59:03+03:00, aelkin@mysql1000.dsl.inet.fi +11 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of a cluster was replicated to another member, got accepted and executed. By that same time effects of the event had been already propagated across the cluster via the cluster communications. In order to avoid double-applying, a replication event generated by a co-member of the cluster should not be accepted. Both variations of the unstoppable replication event are fixable with introducing a new option for CHANGE MASTER: IGNORE_SERVER_ID= (sid_1, sid_2, ... ) The option can be set to the empty list that resets. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing IGNORE_SERVER_ID list by the following CHANGE MASTER ... IGNORE_SERVER_ID= (list), the empty list arg nullifies the current ignored list; c. preserving the existing list by CHANGE MASTER w/o IGNORE_SERVER_ID; d. resetting the ignored server ids with RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id. Use cases for this feature can be found on the bug report page.
[3 Jun 13:36]
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/47357 ChangeSet@1.2634, 2008-06-03 14:36:57+03:00, aelkin@mysql1000.dsl.inet.fi +12 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of a cluster was replicated to another member, got accepted and executed. By that same time effects of the event had been already propagated across the cluster via the cluster communications. In order to avoid double-applying, a replication event generated by a co-member of the cluster should not be accepted. Both variations of the unstoppable replication event are fixable with introducing a new option for CHANGE MASTER: IGNORE_SERVER_IDS= (sid_1, sid_2, ... ) The option can be set to the empty list that resets. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing IGNORE_SERVER_IDS list by the following CHANGE MASTER ... IGNORE_SERVER_IDS= (list), the empty list arg nullifies the current ignored list; c. preserving the existing list by CHANGE MASTER w/o IGNORE_SERVER_ID; d. preserving the ignored server ids after RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log constists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. g. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. h. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id (yet another feature for the user!). Use cases for this feature can be found on the bug report page.
[4 Jun 18:39]
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/47448 ChangeSet@1.2634, 2008-06-04 19:39:28+03:00, aelkin@mysql1000.dsl.inet.fi +12 -0 Bug #25998 problems about circle replication Bug #27808 Infinite looping in circular replication In case of withdrawing one of the servers from the circular multi-master replication group events generated by the removed server could become unstoppable (bug#25998). That's because the originator had been the terminator of the own event flow. Other possibility of the unstoppable event is the cluster replication (bug#27808). In that case an event generated by a member of a cluster was replicated to another member, got accepted and executed. By that same time effects of the event had been already propagated across the cluster via the cluster communications. In order to avoid double-applying, a replication event generated by a co-member of the cluster should not be accepted. Both variations of the unstoppable replication event are fixable with introducing a new option for CHANGE MASTER: IGNORE_SERVER_IDS= (sid_1, sid_2, ... ) The option can be set to the empty list that resets. Fixed with implementing the feature. Properties of the feature: a. reporting an error if the id of an ignored server is the slave itself and its configuration on startup was with --replicate-same-server-id; b. overriding the existing IGNORE_SERVER_IDS list by the following CHANGE MASTER ... IGNORE_SERVER_IDS= (list), the empty list arg nullifies the current ignored list; c. preserving the existing list by CHANGE MASTER w/o IGNORE_SERVER_IDS; d. preserving the ignored server ids after RESET SLAVE; e. extending SHOW SLAVE STATUS with a new line listing ignored servers; f. a new line in master.info with the list of ignored servers; g. Differently from --replicate-same-server-id handling, the sql thread is not concerned with the ignored server ids, because it's supposed that the relay log consists only of events that can not be unstoppable. In order to guarantee that, e.g in case of the circular replication with a failing server DBA needs to change master necessarily using the new option. h. Rotate and FD events originated by the current master listed in the ignored list are still relay-logged which does not create any termination issue. i. The possible list of ignored servers is sorted for the fastest processing of filtering algorithm. Two new lines to show slave status output are added: the list of ignored servers and the current master server id (yet another feature for the user!). Use cases for this feature can be found on the bug report page.
[18 Jul 16:59]
Andrei Elkin
pushed to 6.0-rpl
[18 Jul 18:14]
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/50050 2674 Andrei Elkin 2008-07-18 bug#25998 updating results
[18 Jul 18: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/50051 2674 Andrei Elkin 2008-07-18 bug#25998 updating results
Description: We use mysql circle replication . Topology look like chart below. A->B->C->A server server-id A 1 B 2 C 3 Server A is replication master of server B,server B is replication master of server C,server C is replication master of server A. When all of servers is health , it work correctly.Every sql in binlog has an property named server-id,when we insert line in server A using SQL "insert into table test values(1)",the property value of this SQL in binlog is 1,when this sql pass to server B, server B find the server-id of SQL is 1,not equal 2,then execute it,the same as c,eventually,the sql pass to A again,but find the server-id is same as itself,so don't execute it. We write program running as as daemon to check replication status between servers,when A is down,B will change new master to C. It work will all the time,but in some monment,when the sql first execute in server A hasn't been pass back to A,as the same time,server A is down,we change new master to C at B, so that sql will be executed in server B and server C for ever. It may not a bug,but may be should be impoved. How to repeat: None