This is the second day of my participation in Gwen Challenge

Redis’s multi-machine solutions fall into three main categories: replication, sentry, and clustering. In this article, we’re going to focus on replication

Copy the replicate

Run the slaveof command or set the slaveof parameter to make one server copy another server. The slave server is copied to the master server and slave server.

Execute on the slave server client:

# slaveof <master_ip> <master_port>
slaveof 127.0.0.1 6379
Copy the code

Or in the redis.conf configuration file of the slave server: slaveof


–slaveof <master_ip> <master_port>

Synchronization and command propagation

Redis replication is divided into two operations: synchronization and command propagation.

The main steps of a synchronization operation are:

  1. The secondary server sends the sync command to the primary server.
  2. The master server receives the sync command and executes the BGsave command, generating an RDB file in the background and using a buffer to record all write commands from now on.
  3. When the primary server finishes executing the BGSave command, it sends the generated RDB file to the secondary server, which loads the file and synchronizes the database library state to the state when the primary server executes the BGSave command.
  4. The master server sends all write commands in the buffer to the slave server, which executes the synchronization.

When the client modifies the database status of the master server, the master server transmits commands to the slave server to keep the database status consistent.

The improvement of Redis2.8

The replication from the secondary server to the primary server can be classified into the following scenarios: First replication and repeat after disconnection.

Prior to Redis2.8, the main server had to execute sync again after disconnection, which was obviously inefficient. The sync command is very resource-intensive.

Starting from redis2.8, the psync command is used instead of the sync command to perform synchronization during replication.

The psync command supports full and partial resynchronization modes. Full resynchronization is the same as before, while partial resynchronization is designed to solve the problem of inefficient replication after disconnection by having the primary server send write commands during disconnection to the secondary server for execution.

So how did he do it? How do you let the master server know what is the data during the outage? Let’s find out. Partial resynchronization consists of the following three parts:

  1. The replication offsets of the master and slave servers.
  2. Replication buffer for the primary server
  3. Running ID of the server

First, the master and slave servers each maintain a replication offset. By comparing the offset directly from the master and slave servers, it is easy to determine whether the master and slave states are consistent. Second, when the master server sends command propagation, it not only sends write commands to the slave server, but also plugs them into the replication buffer. It is constructed to record the offset and the corresponding byte value. Finally, the primary server run ID saved by the secondary server (at the time of the first replication) tells you whether you were previously connected to this primary server and can determine whether to perform partial or full resynchronization.

reference

  1. Redis Design and Implementation