Replica Lag

What replica lag tells you about replication health

Replica lag is best understood as a freshness and consistency signal, not just a timing metric. It shows whether the replica is keeping pace with the source database and whether read traffic, failover planning, or migration cutover can rely on what the replica currently contains.

In practice, the meaning of the number depends on the workload. A small, stable lag is usually manageable, but increasing or erratic lag can mean the replica is under-provisioned, the source is generating more change than the replica can apply, or downstream processing is delaying replay.

Why lag matters during migration and promotion

Replica lag becomes operationally important when the replica is expected to take over as the new primary. Near-zero lag suggests the target has absorbed almost all recent writes, which reduces the chance that a promotion will lose committed data or expose users to stale state.

Migration teams use this signal to decide when the system is close enough to switch reads, start validation, or execute cutover. If the lag remains persistent, the replica is not yet a safe substitute for the source because application state may diverge at the moment of promotion.

Common causes of delayed replication

Lag is usually a symptom of capacity, topology, or workload mismatch. High write volume, large transactions, slow storage, network latency, lock contention, or expensive replay work on the replica can all delay how quickly changes become visible.

It can also appear when the replica is doing more than passive replication, such as serving reads, running analytics, or sharing infrastructure with other workloads. In those cases, the database may still be healthy overall, but the replication pipeline is being asked to do too much for the required freshness target.

How to interpret replica lag operationally

The key question is not whether lag exists, but whether it is acceptable for the business function that depends on the replica. For read scaling, some delay may be tolerable. For failover, data migration, or zero-data-loss goals, the same delay may be a blocker.

Teams should treat lag as a readiness check alongside replication status, recent write activity, and application consistency requirements. The most useful interpretation is always contextual: the same number can be harmless in one workload and unacceptable in another.

Risk and Threat Considerations

Replica lag creates a data consistency risk because a cutover or failover can expose users to stale records, missing writes, or split-brain behaviour if the replica is promoted too early. It also increases the chance that troubleshooting, reporting, or operational decisions are made against data that is not yet current.

Failure mechanism: Writes accumulate on the source faster than the replica can apply them, or replay is delayed by resource bottlenecks, so the replica is promoted before it has fully caught up.

Impact: The organisation can lose recent committed data, serve inconsistent application state, or extend an outage while teams validate and recover from an avoidable bad cutover.

Practitioner Guidance

What to watch for: Track lag against the migration or failover objective, not as a standalone health metric. A replica that is “healthy enough” for read scaling may still be unsafe for promotion if the application depends on near-real-time consistency.

Governance implication: Treat promotion criteria as an explicit operational decision, with a defined freshness threshold, rollback plan, and owner who can stop the cutover when lag is above tolerance.

Practitioner takeaway: Replica lag is most useful when it is tied to a concrete readiness threshold, because the same delay can range from acceptable read staleness to unacceptable cutover risk.

Related resources from NHI Mgmt Group

• Why does sync lag create risk for NHI governance?
• Why does ACH settlement lag create more fraud risk than card payments?
• Deprovisioning Lag
• Retrospective detection lag