A Redis replica reconnects after a 20-second network blip and performs a full resynchronization instead of a partial one. Which mechanism should have prevented that, and how do you tune it?

## The backlog is the whole trick Redis maintains, on every primary that has (or recently had) replicas, a fixed-size circular buffer called the replication backlog holding the most recent bytes of the replication stream. It exists solely so a briefly disconnected replica can resume rather than restart. Independently, the primary tracks a monotonically increasing offset: the total number of replication-stream bytes ever produced in the current history, and a replication ID naming that history. ## What happens on reconnect The replica remembers the last offset it applied and the replication ID it was following. It reconnects and sends `PSYNC <replid> <offset+1>`. The primary checks two things. First, does the requested replication ID match its own current ID (or, thanks to PSYNC2, its recorded previous ID)? Second, is `offset+1` still within the range currently held in the backlog? If both are satisfied, it answers `+CONTINUE` and writes only the missing byte range, and the replica is caught up in milliseconds. Otherwise it answers `+FULLRESYNC` and pays for a fork, a snapshot and a full transfer. ## Why 20 seconds was enough to lose it The backlog defaults to 1 MB, which is tiny for anything but a low-traffic instance. If the primary produces, say, 2 MB/s of replication stream, the entire buffer is overwritten every half second, so any disconnection longer than that is unrecoverable by partial resync. Compute the requirement directly: `repl-backlog-size >= peak_write_bytes_per_second * max_tolerated_disconnect_seconds`. To measure the numerator, sample `master_repl_offset` from `INFO replication` a few seconds apart and divide the delta by the interval, at peak traffic rather than at the daily average. Then add headroom, because the cost is a fixed allocation on the primary and not proportional to the dataset. ## The other reasons a full sync happens - **Replication ID mismatch.** If the primary process restarted, it comes up with a fresh history and no memory of the old one (unless it reloaded an RDB that stores the replid), so every replica must fully resync. Repointing a replica at a different primary has the same effect. - **Backlog released.** `repl-backlog-ttl` (default 3600 seconds) frees the buffer once no replica has been attached for that long, so a replica that has been away longer cannot resume. - **Promotion without PSYNC2 support.** Before Redis 4.0, promoting a replica to primary changed the history and forced all sibling replicas into full syncs. PSYNC2 fixed this: a promoted replica keeps the old replication ID as a secondary ID (`master_replid2` with `second_repl_offset`), so siblings that were following the old primary can partially resync against it. Chained sub-replicas also preserve offsets across the change. ## Operating it `INFO stats` gives you `sync_full`, `sync_partial_ok` and `sync_partial_err`. A healthy deployment with occasional network noise should show partial successes climbing and full syncs staying near constant; a rising `sync_full` means real load on the primary each time. `INFO replication` exposes `repl_backlog_active`, `repl_backlog_size`, `repl_backlog_first_byte_offset` and `repl_backlog_histlen`, from which you can see how much history you actually hold. Note also that the backlog is not the same thing as the per-replica output buffer that fills during a full sync; both can force a full resync, but the backlog covers reconnects while the output buffer covers the initial transfer window, and they are tuned separately. The judgement call is simply memory: a few hundred megabytes of backlog on a primary is usually far cheaper than repeated forks, transfer bandwidth and degraded replicas whenever the network hiccups.