MySQL Replica Lag Is More Than One Number

Replica lag can mean several different delays: events have not arrived, events are waiting to be applied, or data has been applied but the application is still reading a different replica. A single time-based field cannot fully describe all three.

Monitor replication as a pipeline and define the user-facing requirement. A background analytics job and a read-after-write account screen usually need different guarantees.

The concrete problem

The example targets MySQL 8.4 asynchronous replication. Start with status inspection, not configuration changes. Multi-source replication requires identifying the channel, and multithreaded appliers require worker-level inspection.

Figure: Source binlog → Receiver and relay log → Applier and readable state.

A worked example

SHOW REPLICA STATUS\G
SELECT CHANNEL_NAME, SERVICE_STATE,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status;
SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_worker;

Why the behavior matters

Separate receiver health from applier health. A working connection can fetch events while a worker is blocked or has stopped with an error. Conversely, an applier can be caught up to its available relay log while the receiver is disconnected. Inspect source positions or GTID progress together with timestamps and errors.

Seconds_Behind_Source is useful context, not a universal freshness SLA. Its interpretation depends on receiver/applier state and workload. A quiet source, clock assumptions and parallel apply can make simplistic dashboards misleading. Build an application freshness probe only if its write and read overhead are acceptable and its semantics are documented.

Failure modes and design tradeoffs

Increasing applier parallelism does not remove every bottleneck. Dependency constraints, storage throughput and long transactions can dominate. Skipping a failing transaction to make a dashboard green can corrupt business consistency and should never be routine troubleshooting.

For read-after-write behavior, decide whether to route a request to the source, wait for a known transaction position or accept stale data explicitly. Avoid treating a replica endpoint as an interchangeable low-latency copy of the source.

What to verify before adoption

Create a controlled insert and track when a designated replica can return it. Test receiver disconnection separately from a slow applier in a disposable topology. Verify that alerts identify the failing stage and that routing uses the intended replica. Document the distinction between replica freshness and recoverable backup history.

Primary reference

• MySQL documentation. Verify the exact deployed version and driver behavior before using the example in a production runbook.