GTID Replication Error: GTID Set Mismatch Detected

Answer the core questions first

1. Recommended command sequence to merge divergent GTID sets on a replica (MariaDB 10.5+)

1. On the replica, stop replication:

   STOP SLAVE;

2. Verify the current GTID state on both nodes:

   SELECT @@global.gtid_executed AS current_gtid_set;
   SELECT @@global.gtid_executed AS source_gtid_set FROM source_host;

3. Set the replica’s executed GTID set to match the source. Replace source_gtid_set with the exact value obtained in step 2.

   SET GLOBAL gtid_executed = 'source_gtid_set';

4. Restart replication:

   START SLAVE;

5. Confirm that replication resumes and the executed GTID set is now identical:

   SHOW SLAVE STATUS\G
   SELECT @@global.gtid_executed;

These steps align the executed GTID set without rewriting data. If the replica had produced transactions during the partition, those transactions will now be considered executed and will not be replayed again.

2. Built‑in gap detection during GTID mode transition

MariaDB does not automatically detect or close GTID gaps that arise from a network partition or an abrupt GTID mode switch. The only automatic behaviour is that, once GTID_MODE is turned on, new transactions are assigned GTIDs by the server. Manual intervention—via SET GLOBAL gtid_executed or SET GLOBAL gtid_slave_pos—is required to reconcile diverging sets.

3. Impact on replication latency and data consistency

• Replication stops for the duration of the STOP SLAVE–START SLAVE window; the replica may lag behind the source by a few seconds to a minute, depending on load.
• Once the GTID sets are aligned, the replica resumes applying new events immediately, restoring low latency.
• No data loss or duplication occurs if the executed GTID set is set correctly; all transactions that were already applied remain marked as executed.
• If the GTID set is set incorrectly, the replica could either skip needed events or replay already applied events, leading to divergence.

Additional precautions and verification

• Ensure both source and replica run binlog_format = ROW and GTID_MODE = ON before performing the merge.
• Take a full backup of the replica before altering gtid_executed—the change is irreversible without a backup.
• After the merge, run a small test transaction on the source and confirm it appears on the replica within a few seconds.
• If replication does not start, check SHOW SLAVE STATUS\G for errors such as Slave_SQL_Running: No or Last_SQL_Errno values indicating a pending transaction or filter conflict.

Missing diagnostic detail needed to proceed

To set the replica’s gtid_executed accurately, we need the exact GTID set string reported by the source. Please run the following on the source and provide the result:

SELECT @@global.gtid_executed;

That value will be used as the argument to SET GLOBAL gtid_executed on the replica.

Summary

In a split‑brain scenario, the safest path is to stop the replica, copy the source’s GTID set into gtid_executed, and restart replication. MariaDB offers no automatic gap resolution during a GTID mode transition, so manual reconciliation is required. The impact is a brief pause in replication, after which consistency and low latency return, provided the GTID sets are aligned correctly.