Redis Replication Deep Dive: PSYNC, Full & Partial Sync, Heartbeats and Async Writes

Replication Process

When a slave executes the SLAVEOF command, it records the master’s address but does not start copying immediately. A scheduled task discovers the master info, opens a socket, sends a PING, performs optional authentication, and then the master streams the entire dataset to the slave. After the initial data transfer, the master continuously forwards write commands to keep the replica consistent.

Data Synchronization (PSYNC)

Redis 2.8 introduced the PSYNC command to replace the older SYNC. PSYNC requires three pieces of information from the master: the replication offset of each node, the master’s replication backlog buffer, and the master’s run‑ID. The slave reports its own offset; the master compares offsets to decide whether a full or partial sync is needed.

Each node maintains its own replication offset, visible in INFO REPLICATION as masterreploffset (master) and reported by the slave.

The master’s backlog is a fixed‑size FIFO queue (default 1 MB) that stores recent write commands for partial sync.

The 40‑byte run‑ID uniquely identifies a Redis instance; a change forces a full sync.

To keep the run‑ID unchanged across a restart, the DEBUG RELOAD command can reload the RDB without generating a new ID, but it blocks the main thread and should be used cautiously.

Full Replication

Full replication is the initial sync performed when a replica is first attached. It can be triggered by SYNC (pre‑2.8) or PSYNC returning +FULLRESYNC. The steps are:

Slave sends PSYNC -1 -1.

Master replies with +FULLRESYNC {runId} {offset}.

Slave records the master’s run‑ID and offset.

Master performs a BGSAVE to generate an RDB file.

Master streams the RDB file to the slave.

Slave loads the RDB into memory.

During loading, the master buffers new writes in the replication client buffer.

After loading, the slave clears its data and continues receiving buffered writes (configurable via slave-server-stale-data).

If AOF is enabled, the slave rewrites AOF after the RDB load.

Large RDB files (>6 GB) may exceed the default 60 s timeout; increasing repl-timeout mitigates this.

Partial Replication

If a replica disconnects briefly, the master can resend only the missing commands stored in the backlog, avoiding a full sync. The process:

When the connection is lost beyond repl-timeout, the master closes it.

The master continues writing new commands to the backlog (default 1 MB).

Upon reconnection, the slave sends its last offset and the master’s run‑ID.

If the missing data is still in the backlog, the master replies +CONTINUE and streams the buffered commands.

Heartbeat Mechanism

After replication is established, master and replica maintain a persistent TCP connection and exchange periodic heartbeats.

Master sends a PING every 10 seconds (configurable via repl-ping-slave-period).

Replica sends REPLCONF ACK {offset} each second to report its current offset.

If the master does not receive an ACK within repl-timeout (60 s), it marks the replica as offline.

Deploying master and replica in the same data center reduces latency and heartbeat interruptions.

Asynchronous Replication

The master writes data locally and forwards write commands to replicas asynchronously; it returns to the client without waiting for the replica to acknowledge.

Master receives a write command.

Master processes it and sends a response to the client.

Master asynchronously pushes the command to replicas, where it is executed in the replica’s main thread.

Conclusion

The article dissected Redis replication, covering the initial sync, the PSYNC‑based data synchronization, full and partial sync flows, heartbeat design, and asynchronous write propagation. Controlling the replication backlog size and timeout settings is crucial to avoid unnecessary full syncs and to maintain high availability.