Master-Master Replication between PXCs

Hi,

Seeing a lot of these:
[COLOR=#B22222][Warning] WSREP: Pending to replicate MySQL GTID event (probably a stale event). Discarding it now.

PXC is Ver 5.7.21-20-57 for debian-linux-gnu on x86_64 (Percona XtraDB Cluster (GPL))

Transactions going into D1, C1, E1, F1 shows up in all PXC nodes. This is great.
Transactions going into A1/B1 does not show up in other/all PXC nodes.
server-id, wsrep node/name/ip are unique per node
wsrep cluster name is unique per cluster.
see attached picture for arch.
Please let me know if this arch works at all or if I am chasing a wild goose. Appreciate it.

photoid=51222

Same story with the following arch too.

----------E1 (Percona Server Server)
----------| (Async Master - Master setup)
----------|------F1 (Percona Server Server)
----------|-------| (Async Master - Master setup)
A1<->A2<->A3 (PXC)
| (Async Master - Master setup)
B1<->B2<->B3 (PXC)
---------|--------| (Async Master - Master setup)
---------|-------C1 (Percona Server Server)
---------| (Async Master - Master setup)
--------D1 (Percona Server Server)

Only hint is [COLOR=#FF0000][Warning] WSREP: Pending to replicate MySQL GTID event (probably a stale event). Discarding it now. Can’t get my head around this.

Experts, you guys only need to confirm what this means…:

[COLOR=#FF0000][Warning] WSREP: Pending to replicate MySQL GTID event (probably a stale event). Discarding it now.

So far, I can confirm the data is flowing fine between both archs.

Let me see if I understood your setup correctly

  1. You have 6 pxc-cluster in all named as A, B, C, D, E, F

  2. Each cluster has 3 nodes

  3. Cluster A and B master-master relationship.
    (what does this mean? does it mean all these 6 nodes form a single big cluster)

  4. Now, each of the remaining cluster C, D, E, F are connected to either of the nodes from A or B.
    [Relationship here is async master-master. Again? what is async master-master? 2-way master-slave link ?]


Possible cause:

  • Is log-slave-updates set on all the nodes of the cluster

  • Also as per one such already filed bug (PXC-2042), user suspect use of binlog_format=MIXED causing the issue. Do you have the same setting.

Hi krunalbauskar,

A1<->B1 are master-master. A1,A2,A3 are in same cluster {PXC}. B1,B2,B3 are in another cluster {PXC}.

Yes, log-slave-updates set on all the nodes of the cluster. Need this to allow writes that needs to get replicated.

binlog_format=ROW as PXC/galera recommends and works.

On a side note: Does Percona-server-server-5.7 support multi-source replication yet? In the above setup, the footprint to support each remote location is high. EG: each node in the cluster is a master master with a remote Percona-server-server-5.7. Hoping to see multi-source replication in Percona releases sooner than later.

Thank you.

Sorry but I still don’t understand what master-master relationship among 2 PXC clusters.

PS-5.7 should have multi-source replication support as MySQL 5.7 added it.
Do you see any issue using it?

Hi krunalbauskar,

Good to know that multi-source replication is ported to PS-5.7.

Thanks for your responses.

Hi, we’ve experienced this same issue while configuring asynchronous bi-directional (master <-> master) MySQL replication between two independent PXC clusters. The solution was to set the same server-id for each host per-cluster. Cluster 1 with 3 members all use server-id 1, cluster 2 with 3 members all use server-id 2. This is required to avoid a replication loop. Now MySQL async replication can ignore transactions that have already been replicated.

Hi krunalbauskar I am noticing this behavior too. We have two PXC clusters, say A and B. A node in cluster B, B1-1, is an async slave of a node in A, A1-1. The following warning messages floods mysql’s error log on B1-1. These messages stop as soon as sql_thread is stopped and continue when slave is started again.

[Warning] WSREP: Pending to replicate MySQL GTID event (probably a stale event). Discarding it now.

We are running PXC 5.7.24. The async replication is not using GTID. This behavior is evident across two different deployments of the same architecture, async master-slave replication b/w two PXC clusters.

Any thoughts?

Related PXC Bug: [URL][PXC-2591] Percona cluster with async gtid replication - Percona JIRA