How Redis Replication Works: From Sync Process to Asynchronous Copy

Replication Principle

1. Replication Process

From the slave node execute slaveof command.

The slave stores the master’s address but does not start replication immediately.

A periodic task on the slave detects the master information and opens a socket connection.

After the connection succeeds, the slave sends a ping and expects a pong; otherwise it retries.

If the master requires authentication, the slave validates credentials; failure aborts replication.

Once authenticated, the master begins data synchronization – the most time‑consuming step – sending all data to the slave.

After the initial data transfer, the master continuously streams write commands to the slave to keep data consistent.

2. Data Synchronization

Redis provides two synchronization commands: sync (pre‑2.8) and psync (introduced in 2.8). The focus here is on psync, which relies on three pieces of information:

Replication offsets of master and slave.

Master’s replication backlog buffer.

Master’s run‑ID.

Each node maintains its own offset. The master records the total bytes written in info replication under masterreploffset. The slave reports its offset each second, allowing the master to store the slave’s offset as well. Comparing these offsets determines data consistency.

The replication backlog is a fixed‑size (default 1 MB) FIFO queue on the master that stores recent write commands. It is created when the slave connects and is used for partial sync and command loss recovery.

Every Redis instance generates a 40‑character run‑ID at startup. If the master restarts and its run‑ID changes, slaves will perform a full sync; otherwise, a debug reload can reload the RDB without changing the run‑ID, avoiding unnecessary full syncs (note: this blocks the master thread).

psync Command Usage

Format: psync{runId}{offset} Parameters: runId: the master’s run‑ID that the slave is replicating. offset: the slave’s current replication offset.

Execution flow (illustrated in the image below): the slave sends psync with its run‑ID (or -1 for a new slave) and offset (or -1 if never synced). The master decides the response: +FULLRESYNC {runId} {offset} – triggers a full sync. +CONTINUE – triggers a partial sync. +ERR – master does not support psync; fallback to sync for full sync.

3. Full Synchronization

Full sync is the initial replication method, triggered by sync (pre‑2.8) or psync (2.8+). The steps are:

Slave sends psync (e.g., psync -1 -1).

Master replies with +FULLRESYNC and provides its run‑ID and offset.

Slave records the master’s ID and offset.

Master performs bgsave to create an RDB snapshot.

Master streams the RDB file to the slave.

Slave loads the RDB into memory.

During transfer, the master buffers new writes; after the slave finishes loading, the buffered writes are sent.

Slave may execute bgrewriteaof if AOF is enabled.

Critical time‑consuming points are highlighted in bold in the original source (RDB generation, transfer, and loading).

Notes:

If the RDB exceeds 6 GB on a gigabit network, the default 60 s timeout may cause failure; increase repl-timeout to fix.

Redis supports “disk‑less” replication (direct network transfer), but it is not production‑ready.

4. Partial Synchronization

When a network interruption occurs after a slave has already synced, the master can resend only the missing commands from the backlog, avoiding a full sync.

If the slave’s connection times out (exceeds repl-timeout), the master breaks the link.

The master writes pending data to the replication backlog (default 1 MB).

When the slave reconnects, it sends its offset and the master’s run‑ID.

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

The slave receives the data and resumes normal replication.

5. Heartbeat Mechanism

After replication is established, master and slave maintain a persistent connection and exchange heartbeat messages.

Both sides simulate a client; client list shows master connections with flag M and slave connections with flag S.

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

Slave sends replconf ack{offset} every second to report its offset.

If the master does not receive a heartbeat within repl-timeout (default 60 s), it marks the slave as offline.

Deploying master and slave in the same data center reduces latency and avoids heartbeat interruptions caused by network partitions.

6. Asynchronous Replication

The master handles reads/writes and asynchronously forwards write commands to slaves, returning to the client without waiting for replication to finish.

Master processes the client command.

Master returns the response to the client.

For write commands, the master asynchronously sends the command to the slave, which executes it in its main thread.

Conclusion

The article analyzed Redis replication, detailing the replication process, data synchronization, full and partial sync workflows, heartbeat design, and asynchronous replication. It emphasized that RDB transfer is the most time‑consuming part, and that the psync command introduced in Redis 2.8 enables efficient incremental replication by using offsets, a replication backlog, and run‑IDs to avoid unnecessary full syncs.