PXC didn't skip the executed gtid

MySQL & MariaDB Percona XtraDB Cluster 5.x
1

The topology of mysql cluster is as follows:
MASTER-A

  • PXC
    ++ SLAVE-B
    Once I change the topology for some reason:
    SLAVE-B(New Master)
  • PXC
    ++ MASTER-A(New SLAVE)

PXC trigger 1062 duplicate entry.

analyze the record trigger 1062, it’s gtid contained by pxc;( in pxc, show master status )

PXC: /usr/sbin/mysqld Ver 5.7.25-28-57 for Linux on x86_64 (Percona XtraDB Cluster (GPL), Release rel28, Revision a2ef85f, WSREP version 31.35, wsrep_31.35)

Percona Server: 5.7.25-28

2

I think it’s very important issue, but it seems no one is interested in it

3

Hello,

I don’t quite understand your replication topology. Does the

means that your PXC cluster replicates events from an async master, and then another async slave is replicating from one of the PXC nodes?

Do the PXC nodes abort with that error, or PXC node being an async slave is reporting that error in SHOW SLAVE STATUS\G ?

4

PXC node being an async slave is reporting that error in SHOW SLAVE STATUS\G ;

Another thing about topology , is right as you describe. PXC works as MIDDLE-MASTER. MASTER-A —> PXC —> SLAVE-B

One example to make it clearer,
7-30 09:00:00
topology:
MASTER-A —> PXC —> SLAVE-B
DDL: create table t6 (id int primary key);
insert into t6 values (1). DO ON MASTER-A
you can query the data id=1 from table t6 in PXC, SLAVE-B

7-30 09:30:00
SHUTDOWN MASTER-A.
CHANGE PXC to be slave of SLAVE-B.
NOW topoplogy:
MASTER-B( called SLAVE-B) → PXC

AND the binlog “insert into t6 values (1).” would replicate from MASTER-B to PXC, AND PXC node being an async slave is reporting that error in SHOW SLAVE STATUS\G ?

As you know, MySQL is GTID_ON, the executed gtid should be skipped, should not be PXC’s SQL_THREAD broken.