GTID auto positioning replication doesn't work correctly on PXC node with new async monitor logic
General
Escalation
General
Escalation
Description
With auto-positioning it is possible to have scenarios where the transactions received in replication channel doesn’t have continuous sequence numbers since replication works by getting the gtids from the source which have not been executed on the target, which may exist even prior to already applied transaction (which would most probably doesn’t have sequence number as expected by newly introduced async monitor logic).
One such Scenario:
Setup a source PS server and execute: set @@session.sql_log_bin=0; create database db1; create table db1.t(a int primary key);set @@session.sql_log_bin=1;
Setup a replica server (without starting replication) and execute: set @@session.sql_log_bin=0; create database db1; create table db1.t(a int primary key);set @@session.sql_log_bin=1;
Execute couple of inserts on source PS server.
Configure replica to replicate transactions from source by skipping some inserts, by configuring the source_log_pos to some advanced position in source’s binary log (with source_auto_position=0). Say start replicating from third insert (So, GTIDs, <UUID:1-2> would not be replicated to replica).
Start replication on replica server and verify that replication works successfully( But GTIDs, <UUID:1-2> would not have been replicated.)
Stop replication on replica server and enable GTID auto positioning (source_auto_position=1). Start replication.
Replication now would hang on the replica server as async monitor would be expecting some other sequence number. Replication will hang and further transactions if any will not be replicated.
With auto-positioning it is possible to have scenarios where the transactions received in replication channel doesn’t have continuous sequence numbers since replication works by getting the gtids from the source which have not been executed on the target, which may exist even prior to already applied transaction (which would most probably doesn’t have sequence number as expected by newly introduced async monitor logic).
One such Scenario:
Setup a source PS server and execute: set @@session.sql_log_bin=0; create database db1; create table db1.t(a int primary key);set @@session.sql_log_bin=1;
Setup a replica server (without starting replication) and execute: set @@session.sql_log_bin=0; create database db1; create table db1.t(a int primary key);set @@session.sql_log_bin=1;
Execute couple of inserts on source PS server.
Configure replica to replicate transactions from source by skipping some inserts, by configuring the source_log_pos to some advanced position in source’s binary log (with source_auto_position=0). Say start replicating from third insert (So, GTIDs, <UUID:1-2> would not be replicated to replica).
Start replication on replica server and verify that replication works successfully( But GTIDs, <UUID:1-2> would not have been replicated.)
Stop replication on replica server and enable GTID auto positioning (source_auto_position=1). Start replication.
Replication now would hang on the replica server as async monitor would be expecting some other sequence number. Replication will hang and further transactions if any will not be replicated.