Replica broken / resync needed
Synchronization between the replica/standby and the primary is broken. Determine whether replication has stopped, how far behind it is and whether the position/GTID chain is broken; then take the right path among skipping an error, waiting, or rebuilding (reseed). Includes a split-brain warning.
What is the overall state of replication?
First read the replication health: are the apply threads running, how large is the lag, is there an error? Also verify that the two nodes are not both accepting writes (split-brain).
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- Replication has stopped / is failing
- Running but far behind (large lag)
- GTID/position broken, inconsistent — rebuild
- Both nodes are writing as primary (suspected split-brain)
Can the error be repaired, or is a rebuild needed?
Examine the apply error. Some errors (duplicate key, missing row) can be resolved by safely skipping a single event; but if there is data inconsistency/corruption, the only correct path is to rebuild the replica.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- A single/few apply errors (skippable)
- Irreparable inconsistency / corruption
Is the lag temporary or persistent?
Look at the lag trend over time. Does it close (catch up) after a temporary load spike, or does it keep growing so that the replica never catches up with the primary?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- Temporary load spike; lag is closing
- Keeps growing; cannot catch up
Solution: skip the apply error carefully
If replication stopped on a single apply error (e.g. a duplicate key) and you are sure the data is genuinely consistent, you can skip that event and continue the stream. This is a last resort; blind skipping creates silent data drift.
Solution: rebuild the replica (reseed / rebuild)
If the position/GTID chain is broken, data has drifted or there is an irreparable error, the only reliable path is to rebuild the replica from a fresh copy taken from the primary.
Root cause: temporary load spike (lag is closing)
Replication is healthy; lag opened up because of a temporary write burst on the primary or network fluctuation, but the replica is catching up.
Root cause: the replica cannot keep up with the primary
The apply (apply/redo) side cannot keep pace with the rate of change produced by the primary; lag keeps growing. Usually single-threaded apply, slow replica hardware or a network bottleneck.
WARNING: split-brain (two primaries) — risk of data loss
If both nodes accept writes in the primary role, conflicting changes accumulate on both sides; this is the most dangerous situation and can lead to data loss. Reducing writes to a single node comes first.