Replication Backlog Time Calculator
Estimate replication backlog catch-up time from sustained write rate, outage volume, usable throughput, apply limits and recovery targets.| Measure | Value | Planning meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.note }} |
| Checkpoint | Status | Evidence | Next action | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.value }} | {{ row.action }} |
| Capacity factor | Usable capacity | Net drain | Catch-up | Target fit | Copy |
|---|---|---|---|---|---|
| {{ row.label }} | {{ row.capacity }} | {{ row.drain }} | {{ row.catchup }} | {{ row.target }} |
A replica catches up only when it can process change data faster than the primary creates more. The unused part of that throughput drains the queue. If new writes arrive at 180 Mbps and the recovery path can sustain 500 Mbps, the old backlog does not disappear at 500 Mbps; it drains at the capacity left after continuing writes, protocol overhead, and any target-side apply limit.
The waiting work may be database write-ahead log (WAL), binlog events, changed storage blocks, file changes, or search-index operations. Monitoring systems may express the delay as bytes, elapsed time, or source and replay positions. These measures answer different questions. Byte lag describes how much work remains, while time lag describes how stale the applied state appears. Neither is automatically a prediction of catch-up time.
Four measurements determine whether a recovery estimate is useful:
- Incoming change rate should come from a sustained workload period, not a quiet instant.
- Current backlog should identify the same replication stage being modeled, such as bytes not yet received or bytes not yet replayed.
- Replication capacity should be observed end-to-end throughput rather than network interface speed.
- Outage duration adds the changes created while normal replication was interrupted.
Compression or deduplication can reduce the change volume sent across the path, but its ratio must represent the replicated data rather than the source dataset as a whole. Protocol overhead reduces raw capacity, while a replica apply ceiling captures a slower replay, flush, indexing, or target-storage stage. The smaller effective limit controls recovery.
A modeled completion time is a planning estimate, not a recovery promise. Workload bursts, packet loss, throttling, compaction, lock contention, cache pressure, and changing compression can all move the real drain rate. Compare the estimate with live byte lag and replay progress, then test the recovery path before committing it to a recovery time objective.
How to Use This Tool:
Use measurements from the same workload and representative time window. The important comparison is between continuing replicated load and sustained usable capacity.
- Enter Incoming change rate, Replication capacity, and their units. Use observed send or apply throughput for capacity.
- Add the Replication outage and any Current backlog. Set either value to zero when it does not apply.
- Open the advanced inputs to account for Compression or dedupe ratio, Protocol overhead, a Replica apply ceiling, and a Backlog safety buffer. A zero apply ceiling leaves the capacity path uncapped.
- Set a Catch-up target when recovery has a required window, then check the convergence, target, headroom, and bottleneck checkpoints. Correct any negative net drain before treating a duration as reachable.
Interpreting Results:
Can catch up means usable capacity exceeds the continuing replicated load when backlog is positive. Falls behind means net drain is zero or negative, so waiting work cannot reach zero under the entered steady rates. Raising nominal bandwidth will not help when the replica apply ceiling is already the smaller limit.
- Catch-up time is the modeled time to drain the buffered total backlog.
- Inside target includes a completion time exactly equal to the target. Target miss means the estimate is longer.
- Steady-state utilization compares continuing load with usable capacity. The page flags utilization below 80% as headroom available and 80% or higher as thin headroom.
- Backlog age expresses the queue as time at the current incoming rate; it is not the same as catch-up time.
Technical Details:
The model treats replication as a queue with continuous arrivals. Rates are normalized to megabits per second, sizes to bytes, and durations to seconds before the queue is evaluated. Decimal GB and TB remain distinct from binary GiB and TiB.
Formula Core:
Incoming replicated load divides the logical write rate by the entered compression or deduplication ratio.
Usable capacity is capacity after protocol overhead, capped by the apply ceiling only when that ceiling is greater than zero.
When no apply ceiling is active, usable capacity is simply raw capacity after overhead. The buffered backlog and net drain are then:
| Symbol | Meaning | Unit |
|---|---|---|
| W | Logical incoming change rate | Mbps |
| c | Compression or deduplication ratio, at least 1 | ratio |
| C | Entered replication capacity | Mbps |
| o | Protocol overhead | % |
| A | Optional replica apply ceiling | Mbps |
| M | Measured current backlog | bytes |
| to | Outage duration | seconds |
| b | Safety buffer | % |
| D | Net drain rate | Mbps |
| T | Catch-up time, valid only when D > 0 for a positive backlog | seconds |
A positive backlog converges only when D > 0. An empty backlog is considered stable when D ≥ 0. A target passes when the reachable catch-up time is less than or equal to the entered target. Calculations retain full numeric precision; display formatting changes with magnitude and does not feed back into the model.
Capacity scenarios multiply raw capacity by 0.5, 0.75, 1, 1.25, 1.5, 2, and 3 before applying overhead and the same apply ceiling. They show sensitivity to a changed path capacity, not a probability forecast.
Limitations:
The calculation assumes constant incoming load, capacity, compression, overhead, and apply performance for the whole recovery period. It does not simulate bursts, pauses, retries, parallel streams, resynchronization scans, checkpoints, storage growth, or phase changes in replay speed.
- Measure capacity on the actual replication and apply path.
- Use byte counters from a consistent replication stage; received, flushed, and replayed positions are not interchangeable.
- Treat the target as a planning comparison. Recovery objectives require operational testing and business approval.
Worked Examples:
One-hour outage with spare capacity
An 80 Mbps incoming stream continues through a one-hour outage, creating 36 GB of backlog. With 200 Mbps raw capacity, 10% overhead, no apply ceiling, and no safety buffer, usable capacity is 180 Mbps and net drain is 100 Mbps. The backlog drains in 2,880 seconds, or 48 minutes, so a one-hour catch-up target passes.
Capacity that never overtakes writes
A 200 Mbps incoming stream and 220 Mbps raw capacity may look close, but 10% overhead leaves 198 Mbps usable. Net drain is −2 Mbps. Any positive backlog grows rather than clears, so adding time cannot produce a reachable completion estimate.
FAQ:
Why does a database lag counter differ from this catch-up estimate?
A reported lag interval may describe recent commit, receive, flush, or replay delay. Catch-up time instead divides a byte backlog by modeled spare throughput. Compare the same stage and collect both byte and time evidence.
Should replication capacity equal the link speed?
Usually not. Use a sustained rate observed while sending and applying representative change data, because encryption, latency, target storage, replay work, and throttling can make the effective rate much lower.
References:
- REL13-BP01 Define recovery objectives for downtime and data loss, AWS Well-Architected Framework.
- The Cumulative Statistics System, PostgreSQL Documentation.
- Manage read replicas, Google Cloud Documentation.
- How to monitor replication in MySQL or MariaDB, Simplified Guide.
- How to check GlusterFS geo-replication status, Simplified Guide.