MySQL replication after a VPN drop: read both stages first

Replication monitoring turns red when the VPN drops, and the instinct is to reset a position. That instinct is how a network interruption becomes a data problem. A dropped path says nothing about what the replica has received or applied, and those are two stages with two states. Read them separately before changing anything.

Two stages, two separate answers

A conventional asynchronous replica does two jobs. The receiver connects to the source, pulls events and writes them to the relay log locally. The applier reads that relay log and executes the events against the replica. When the path breaks, the receiver stops immediately while the applier continues working through whatever backlog is already on disk. One outage therefore produces two different questions: is the connection back, and has the accumulated work been applied? Treating them as one question averages two states into a misleading answer.

The receiver recovering tells you the path is up. It says nothing about how far behind the applier is, or whether it hit an error while disconnected.

Read the channel with the right statement

On MySQL 8.4, SHOW REPLICA STATUS returns one row per configured channel, so read the row for the channel you mean rather than the first one listed. Replica_IO_Running separates a connected receiver from one that is connecting or stopped, and Replica_SQL_Running describes the applier. Read the error columns alongside them, because a receiver that reconnects and immediately fails leaves a message no status flag will show. Older releases use different column names, so do not translate an old recipe by renaming commands alone.

Check the source identity and any configured filters too. A replica pointed at the wrong source, or filtered more narrowly than you think, reports healthy while replicating something other than what you expect.

Why a zero lag number can lie

The lag value compares the timestamp of the last applied event with the current time. When the receiver has been stopped for an hour, the applier can work through the backlog and reach the end of what it received, at which point the number falls to zero even though the replica is an hour behind the source. The metric measures the applier's queue, not the replica's currency.

Compare executed transactions against what the source has available instead. That comparison survives a stalled receiver.

Retention sets the real recovery window

Catching up requires the source to still hold the transactions the replica needs. Once those are purged, the replica cannot fetch them, and no amount of reconnecting changes that.

With GTID auto-positioning the failure is explicit: the replica asks for history the source no longer holds and refuses to continue. The options then are getting the missing events from a source that still has them, or rebuilding from a backup and letting it catch up. Skipping the gap is not catching up, and it leaves a replica whose data is quietly incomplete. Plan the window by comparing expected outage length with binary log retention on the source and the change rate, because those three numbers decide whether an outage is recoverable at all.

Verify catch-up, not the colour of an indicator

Restore the path, including name resolution and transport security, then watch whether the existing channel reconnects on its own policy. Give it a defined interval before intervening, and record receive and apply progress at both ends of that interval. A channel that restarts and a channel that is current are different findings.

Confirm the applier has reached the source's current position, not merely the end of the old backlog. Check that no error is waiting in the applier, since one failed event stops progress while the receiver keeps reporting connected. Then record the evidence: channel name, both stage states, the executed position and the time. A green indicator is a claim; the position is a fact.