MySQL Bugs: #25998: problems about circle replication

Bug #25998	problems about circle replication
Submitted:	1 Feb 2007 3:06	Modified:	1 Sep 2009 8:50
Reporter:	mingfei hua	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.0.27	OS:	Linux (linux)
Assigned to:	Andrei Elkin	CPU Architecture:	Any
Tags:	change master IGNORE_SERVER_IDS, circular replication

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

Thank you for the report.

Verified as described.

Duplicate of BUG#27808.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

pushed to 6.0-rpl

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

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

Pushed into 6.0.10-alpha (revid:luis.soares@sun.com-20090129165607-wiskabxm948yx463) (version source revid:luis.soares@sun.com-20090129163120-e2ntks4wgpqde6zt) (merge vers: 6.0.10-alpha) (pib:6)

Documented feature addition in the 6.0.10 changelog as follows:

        In circular replication, it was sometimes possible for an event
        to propagate such that it would be reapplied on all servers.
        (This could occur when the originating server was removed from
        the replication circle and so could no longer act as the
        terminator of its own events, as normally happens in circular
        replication.)

        In order to prevent this from occurring, a new
        IGNORE_SERVER_IDS option is introduced for
        the CHANGE MASTER TO statement. This option
        takes a list of replication server IDs; events having a server
        ID which appears in this list are ignored and not applied. For
        more information, see CHANGE MASTER TO Syntax.

Also updated http://dev.mysql.com/doc/refman/6.0/en/change-master-to.html, http://dev.mysql.com/doc/refman/6.0/en/show-slave-status.html, and http://dev.mysql.com/doc/refman/6.0/en/slave-logs-status.html with option syntax, changes in SHOW SLAVE STATUS output and of contents of master.info file.

Setting Status to Verified and requesting that this fix be backported to telco-6.3 and telco-6.4 trees, given that (a) we also support circular/multi-master replication for geo-replication and (b) there is another, highly relevant, potential application of this option unique to Cluster (see AElkin's comments in Bug#27808). 

I think it might be a serious mistake *not* to make this available to Cluster 6.3/6.4 users. 

I'm not sure whether it would be worth the time/effort to include this fix in telco-6.2, and I believe we should not include it in 5.1-main, since GA status precludes feature changes of this type.

See BUG#47037.

Addition to changelog entry:

In conjunction with the introduction of IGNORE_SERVER_IDS, SHOW SLAVE
STATUS has two new fields. Replicate_Ignore_Server_Ids displays
information about ignored servers. Master_Server_Id displays the
server_id value from the master.