Recovering a Single Table on a MySQL Slave When GTID Replication Errors Occur

When a table on a MySQL replica becomes inconsistent with the master and replication stops with a GTID error, rebuilding the whole replica can be time‑consuming; the following methods show how to recover only the affected table.

Scenario 1

If replication stopped and no error‑skip or filter was applied, the master continues updating while the replica is stuck at GTID aaaa:1-100.

Correct repair steps:

Backup table t on the master (snapshot GTID aaaa:1-10000).

Restore the backup to the replica.

Start replication, skipping the transactions that modify t between GTID aaaa:101 and aaaa:10000.

Implementation example:

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');

Then start replication up to the snapshot point:

START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';

Finally, remove the replication filter and resume normal replication. Use mysqldump --single-transaction --master-data=2 to record the GTID of the backup.

Scenario 2

If error‑skip or filtering was already used and both master and replica keep updating, the replica may miss transactions that modify t between GTID aaaa:10001 and aaaa:20000.

Correct repair steps:

Lock table t for read on the replica.

Backup table t on the master.

Stop replica replication, restore the backup of t.

Start replication.

Unlock table t.

For large tables, consider using transportable tablespace to reduce lock time.

Keywords: #replication #data recovery #GTID