Redis's master-slave synchronization

Synchronous

Why should Redis implement master-slave synchronization?

Master-Slave synchronization, with the following benefits:

1. Realize the backup of data, reduce the loss of single point of failure;
2. Helps to achieve load balancing. Originally a server responsible for all the data read and write, and through the master-slave synchronization, you can have more than the server is responsible for data read, and the main server is responsible for the data write, reduce the single point of pressure.

Partial resynchronization

Redis starting from 2.8, the introduction of Psync, support partial resynchronization: The primary server and disconnected from the server during this time, the primary server data may be only a small number of changes, then when the primary server re-connected from the server, there is no need to send the data from the primary server to the server for data coverage, only to the inconsistent Data to the slave server, which avoids the primary server for data backup and network transmission of data.

The process of synchronization

The following uses two machines, a (10.15.62.11:6379) as the slave server, B (10.15.62.12:6380) as the primary server, describes A and b for the first full synchronization and partial resynchronization process.

2. A slaveof 10.15.62.12 6380 command is sent to a by the client, and a is returned to the client after a command is received +ok;
4. Establish sockets between A and B;
6. A send ping command to B, there are two purposes: 1) Verify that the socket between AB has no problem; 2) b server can handle the command, external service.
8. B to a return to pong;
10. If a masterauth is set, it indicates that authentication is required. Then a will send the auth command to B, and the command parameter is the value of Masterauth.
12. If a sends a value that is the same as B's Requirepass value, it is validated.
14. A to B send replconf Listening-port 6379,b will save the port of a, the only purpose is: Users use the client to B send info replication command, display from the server port.
16. A to B send Psync? -1;
18. b After accepting the Psync command, send the Run-id and own copy offset to A,a will save the run ID of B and copy offset of B as its own copy offset; b then perform the bgsave operation, generate an RDB data from the subprocess, Also save the write commands received during the execution of the Bgsave command.
20. B sends the RDB data to A,a to empty its database, loads the RDB data of B into memory, and B sends the copy command to a.
22. Synchronization completed;
24. When writing data to B, B passes the command to a.
26. A and B are suddenly disconnected;
28. A and B reconnect;
30. A to B send Psync <run-id> <offset>......run-id is the run of the master server that you save Id,offset is its own copy offset.
32. b receives the Psync and its parameters, discovers that the run ID is the same as its own run ID, and finds that the data after offset is in its own replication backlog, requiring only partial resynchronization and returning a +continue to a.
34. b Send the data inside the backlog buffer to a.
36. Synchronize again.

Code implementation:

Not to be continued.

Resources:

"Redis Design and Implementation" chapter 15th

A brief analysis of Redis master-slave synchronous source-slave

Redis's master-slave synchronization