A read replica that falls further and further behind — or serves rows that are minutes or hours old — usually isn't "lagging" in the normal sense. Its SQL thread has stopped on an error, so it stopped applying changes entirely while the primary kept moving.
Check replication status
SHOW REPLICA STATUS\G # Replica_SQL_Running: No <- stopped # Last_SQL_Error: ... <- why # Seconds_Behind_Source: NULL <- not applying at all
The error log has the detail — often a Duplicate entry for key 'PRIMARY' or a missing row, meaning the replica and primary have diverged.
Restart it — carefully
If the failed statement is genuinely safe to skip (you've confirmed the data already matches), you can skip the offending event and resume:
-- only after confirming the rows are consistent: SET GLOBAL sql_slave_skip_counter = 1; START REPLICA; SHOW REPLICA STATUS\G -- Replica_SQL_Running: Yes
Blindly skipping errors hides real divergence — if the data has drifted, the honest fix is to re-seed the replica from a fresh backup. Also make sure each server has a unique server-id; a clash stops replication from starting at all.
Practise it
Replica failures are part of the simulator's database incidents, next to repairing a corrupted table. Work them in a full incident response shift.