Replica Lag (seconds), kpi

​

At a glance

How many seconds behind the primary each replica is. Redis replication is asynchronous, so a replica always trails the primary by some amount; the question is how much. A few hundred milliseconds is normal. Ten seconds or more means the replica has fallen so far behind that promoting it during a failover would lose the last ten seconds of writes, and any reads served from it are stale by that much. For a platform team this is “if my primary dies right now, how much data do I lose, and how stale is everything my read-replicas are serving?”

​

Calculation

replica_lag_seconds = master_last_io_seconds_ago   (read on the replica)

• master_last_io_seconds_ago is a connectivity proxy, not a byte-offset. It tells you the replica heard from the primary recently; it does not directly measure how many bytes behind it is. For exact byte lag you compare master_repl_offset on the primary against the replica’s offset. The card uses master_last_io_seconds_ago because it is the field exposed on the replica and rises sharply the instant the replication link stalls, which is the failure mode that matters most.
• master_link_status gates the reading. If master_link_status:down the replica is not connected at all; the card surfaces that as a broken link rather than a lag number, because “lag” is meaningless when the stream is severed.
• A value of -1 or a very large number indicates the replica has never synced or has lost the link entirely. The engine treats these as the maximum-severity case, not as “0 seconds behind”.
• Per-replica reporting. A primary with three replicas yields three readings; one slow replica (often a cross-region one) can be lagged while the others are healthy. The headline is the worst replica, but all are available for drill-down.

​

Worked example

1. replica-a is healthy at 0 seconds. In-region, low network latency, keeping pace with the write batch.
2. replica-b is 23 seconds behind. The link is up, so this is not a disconnect, it is genuine lag. The cross-region link (eu-west-1 to us-east-1, around 70 to 90 ms RTT) cannot keep up with the burst of writes from the reindex, so the replication buffer is draining slower than it fills.
3. What is the impact? The reporting workload reading from replica-b is serving data 23 seconds stale. For a reporting dashboard that is usually fine. But if replica-b were a failover candidate, promoting it now would lose 23 seconds of writes, which for an order or session store is unacceptable.

Risk framing:
  - replica-b lag: 23s and climbing during the batch
  - Cross-region RTT ~80ms; write burst ~few hundred thousand keys
  - Failover safety: replica-a (0s) is the correct promotion target,
    NOT replica-b (23s) which would lose ~23s of writes
  - Read staleness: reporting on replica-b is acceptable; serving
    user sessions from it would not be

Action:
  1. Ensure replica-a (in-region) is the configured failover priority
     (replica-priority lower number = higher priority)
  2. Confirm the lag drains back toward 0 after the batch completes
  3. If replica-b lag is chronic, raise repl-backlog-size or move the
     reporting workload to a same-region replica

1. Lag is the data-loss budget for a failover. N seconds of lag means promoting that replica loses up to N seconds of writes. For order and session stores, set replica-priority so the lowest-lag replica is always promoted first.
2. Cross-region replicas lag during write bursts, and that is physics. An 80 ms link cannot stream a burst as fast as an in-region one. Size repl-backlog-size so a transient burst does not trigger a full resync, and do not put failover-critical or session reads on a cross-region replica.
3. Link up plus high lag is different from link down. Up plus lag means the stream is flowing but slowly (network or write-rate bound). Down means the replica must resync from scratch (a partial or full sync), which is a far more severe event. Pair with Connected Replicas to see if the link dropped entirely.

​

Sibling cards

​

Reconciling against the source

redis-cli INFO replication run on the replica shows role:slave, master_link_status, master_last_io_seconds_ago, and slave_repl_offset. The master_last_io_seconds_ago line is exactly what the card reads. redis-cli INFO replication run on the primary lists each replica with slaveN:ip=...,offset=...,lag=.... Compare the primary’s master_repl_offset against each replica’s reported offset for the exact byte lag. The offset difference in bytes (master_repl_offset on primary minus the replica’s offset) is the precise lag; master_last_io_seconds_ago is the time-based proxy the card surfaces.

ElastiCache / MemoryDB: the CloudWatch metric ReplicationLag (in seconds) is the direct equivalent and the canonical figure for AWS-managed clusters. Compare it node by node against the card. Azure Cache for Redis: geo-replication lag is reported in Azure Monitor for the geo-replica link. Redis Cloud (Redis Enterprise): the Active-Active / replica-of lag is reported in the database metrics view.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre