Not the answer you need?
Register and ask your own question!

Master-Master Replication between PXCs

MySQLDBA2007MySQLDBA2007 EntrantCurrent User Role Beginner
Hi,

Seeing a lot of these:
[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.

Comments

  • MySQLDBA2007MySQLDBA2007 Entrant Current User Role Beginner
    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 [Warning] WSREP: Pending to replicate MySQL GTID event (probably a stale event). Discarding it now. Can't get my head around this.
  • MySQLDBA2007MySQLDBA2007 Entrant Current User Role Beginner
    Experts, you guys only need to confirm what this means...:

    [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.
  • krunalbauskarkrunalbauskar Advisor Inactive User Role Novice
    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.
  • MySQLDBA2007MySQLDBA2007 Entrant Current User Role Beginner
    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.
  • krunalbauskarkrunalbauskar Advisor Inactive User Role Novice
    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?
  • MySQLDBA2007MySQLDBA2007 Entrant Current User Role Beginner
    Hi krunalbauskar,

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

    Thanks for your responses.
  • 1010100010101000 Entrant Current User Role Beginner
    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.
  • shredder12shredder12 Entrant Legacy User Role Novice
    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?
  • lalit.choudharylalit.choudhary Percona Percona Staff Role
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.