Walk through what happens on both the primary and the replica during a Redis full synchronization, when a replica connects for the first time.

## The handshake A replica drives the process. After connecting it sends PING to check the link, authenticates if needed, announces itself with `REPLCONF listening-port` and `REPLCONF capa eof capa psync2`, and then asks to synchronize with `PSYNC <replid> <offset>`. On a first connection it has no history, so it sends `PSYNC ? -1`. Every replication stream is identified by a pair: a replication ID (a random 40-character string identifying a history) and a byte offset into that history. Those two values are what make later partial resynchronization possible. ## The primary's side Seeing an unknown history, the primary answers `+FULLRESYNC <replid> <offset>`, telling the replica which history it is joining and at which byte position the snapshot corresponds to. It then needs a consistent point-in-time image of the dataset, which it gets by forking a child process; the child serializes the data in RDB format while the parent keeps serving commands. There are two transfer modes. With `repl-diskless-sync no` the child writes an RDB file to disk and the parent then streams the file, which is useful when several replicas sync at once because one file can serve them all. With diskless replication, the default from Redis 6, the child writes the serialized data directly into the replica sockets, avoiding disk I/O entirely, which matters on slow disks or when the working set is large relative to the disk. `repl-diskless-sync-delay` makes the primary wait a moment so that multiple replicas arriving together can share a single child. Crucially, the primary does not stop accepting writes. Everything that happens after the fork point is appended to the new replica's client output buffer so it can be replayed once the snapshot is loaded. That buffer is bounded by `client-output-buffer-limit replica 256mb 64mb 60`. If the write rate multiplied by the transfer time exceeds the limit, the primary closes the connection, the replica retries, and you get an endless full-sync loop that shows up as a climbing `sync_full` counter and repeated forks. Raising the limit or reducing transfer time is the fix. ## The replica's side The replica receives the snapshot, then flushes its existing dataset and loads the new one. Loading is a foreground, CPU-bound operation that blocks that instance; for large datasets it takes real time. `replica-serve-stale-data yes` (default) means the replica answers reads with whatever it has during link loss and sync, at the risk of serving stale or, on a first sync, empty results; setting it to `no` makes it reply `-MASTERDOWN` to most commands, trading availability for the guarantee of not lying. Redis 6 added `repl-diskless-load` (`disabled`, `on-empty-db`, `swapdb`) so a replica can parse the stream directly from the socket instead of writing a temporary RDB file first, with `swapdb` keeping the old dataset in memory as a fallback until the new one is fully loaded. Once loaded, the replica applies the buffered write stream and then continues consuming it live. From that point it sends `REPLCONF ACK <offset>` roughly every second, which is how the primary knows each replica's progress; the primary pings replicas every `repl-ping-replica-period` seconds (default 10) so link failures are detected. ## What it costs, and how to avoid it A full sync is the expensive path: a fork (with copy-on-write page churn that can spike the primary's memory usage on a write-heavy workload), a full serialization of the dataset, the network transfer, and a blocking load on the replica. That is why the rest of Redis replication is designed to avoid it, using partial resynchronization for reconnections. Observability lives in `INFO`: `rdb_bgsave_in_progress`, `sync_full`, `sync_partial_ok`, `sync_partial_err`, and on the replica `master_sync_in_progress` and `master_link_status`. A production instance whose `sync_full` counter keeps rising has a problem worth investigating, because each occurrence loads the primary and briefly degrades the replica.