table of Contents
1. Copy process
The process steps for copying are as follows:
1. The slave node executes the slaveof command;
2. The slave node just saves the information of the master node in the slaveof command, and does not immediately initiate replication;
3. The timing task inside the slave node finds that there is information about the master node, and starts to use socket to connect to the master node ;
4, after the connection is established, send a ping command, hoping to get pong command response, otherwise it will be re-connection;
5, if the master node set permissions, then the need for authority verification; if the validation fails, replication termination;
6, privileges After the verification is passed, data synchronization is performed. This is the longest time-consuming operation. The master node will send all data to the slave node;
7. After the master node synchronizes the current data to the slave node, the establishment of replication is completed Process. Next, the master node will continue to send write commands to the slave nodes to ensure the consistency of the master-slave data.
2. Synchronization between data
In the replication process mentioned above, one of the steps is "synchronizing the data set", this is the "synchronization between data" that is now talking about.
There are 2 commands for redis synchronization:
sync and psync , the former is a synchronization command before redis 2.8, and the latter is a new command designed by redis 2.8 to optimize sync. We will focus on the 2.8 psync command.
The psync command requires 3 component support:
1. The master and slave nodes replicate their respective offsets;
2. The master node replicates the backlog buffer;
3. The operation ID of the master node;
The respective replication offsets of the master and slave nodes:
1. The master and slave nodes participating in the replication will maintain their own replication offset.
2. After the master node has processed the write command, it will accumulate and record the byte length of the command. The statistical information is in the masterreploffset indicator in info replication.
3. The slave node reports its replication offset to the master node every second, so the master node will also save the replication offset of the slave node.
4. After the slave node receives the command sent by the master node, it will also accumulate its own offset, and the statistical information is in info replication.
5. By comparing the replication offset of the master and slave nodes, it can be judged whether the data of the master and slave nodes are consistent.
Master node replication backlog buffer:
1. The replication backlog buffer is a fixed-length first-in-first-out queue stored in the master node. The default size is 1MB.
2. This queue is created when the slave connects. At this time, when the master node responds to the write command, it will not only send the command to the slave node, but also write the copy buffer.
3. His role is to remedy the loss of partial copy and copy commands. You can see related information through info replication.
Running ID of the master node:
1. When each redis is started, a 40-bit running ID is generated.
2. The main function of the running ID is to identify the Redis node. If the ip+port method is used, if the master node restarts and modifies the RDB/AOF data, it will be unsafe for the slave node to replicate based on the offset. Therefore, when the running id changes, the slave node will perform full replication. In other words, after redis restarts, the slave node will perform full replication by default.
What if the running ID is not changed during restart?
1. You can reload the RDB through the debug reload command and keep the running ID unchanged. So as to effectively avoid unnecessary full copy.
2. His disadvantage is: the debug reload command will block the main thread of the current Redis node, so it needs to be used with caution for the main node with a large amount of data or the node that cannot tolerate blocking. This problem can generally be solved through a failover mechanism.
How to use the psync command:
命令格式为： psync{
runId}{
offset}
runId: the running id of the master node copied from the node
offset: the offset of the current data copied from the node
psync execution process:
process description: the slave node sends the psync command to the master node, runId is the ID of the target master node, if it does not default to -1, offset is the copy offset saved by the slave node, if it is the first copy, it is -1.
The master node will decide to return the result according to runid and offset:
1. If you reply +FULLRESYNC {runId} {offset}, then the slave node will trigger the full copy process.
2. If reply +CONTINUE, the slave node will trigger partial replication.
3. If you reply +ERR, it means that the master node does not support the psync command of 2.8 and will use sync to perform full replication.
Up to this point, the synchronization between data is about the same, and the length is relatively long. Mainly for the introduction between the psync commands.
3. Full copy
Full replication is the earliest replication method supported by Redis, and it is also a stage that the master and slave must go through when they first establish replication. The commands that trigger full replication are sync and psync. As I said before, the watershed version of these two commands is 2.8. Before redis 2.8, sync can only perform full differences. After 2.8, it supports both full synchronization and partial synchronization.
The process is as follows:
Introduce the steps in the above figure: the
following bold parts are the time-consuming parts of the entire full synchronization.
1. Send the psync command (spync ?-1)
2. The master node returns FULLRESYNC according to the command.
3. The slave node records the master node ID and offset
4. The master node bgsave and saves the RDB to the local
5. The master node sends the RBD file to the slave node
6. , The slave node receives the RDB file and loads it into the memory.
7. The master node saves the new data to the "copy client buffer" during the period when the slave node receives data. When the slave node finishes loading the RDB file, it will be sent. (If the slave node takes too long, it will cause the buffer overflow, and finally the full synchronization will fail)
8. Load the RDB file after clearing the data from the node. If the RDB file is large, this step is still time-consuming. If the client accesses , It will cause data inconsistency, you can use the configuration slave-server-stale-data to close it.
9. After the RBD is successfully loaded from the node, if AOF is turned on, bgrewriteaof will be done immediately.
note:
1. If the RDB file is larger than 6GB and it is a gigabit network card, Redis's default timeout mechanism (60 seconds) will cause the full copy to fail. This problem can be solved by increasing the repl-timeout parameter.
2. Although Redis supports diskless replication, that is, it is sent directly to slave nodes through the network, but the function is not very complete, so use it with caution in the production environment.
4. Partial copy
When the slave node is replicating the master node, if there is a network interruption or other abnormalities, the slave node will make the master node reissue the missing command data. The master node only needs to send the data in the replication buffer to the slave node to ensure the data. Consistency, compared with full copy, the cost is much lower.
Proceed as follows:
1. When the slave node has a network interruption and the repl-timeout time has elapsed, the master node will interrupt the replication connection.
2. The master node will write the requested data to the "replication backlog buffer", which is 1MB by default.
3. When the slave node recovers and reconnects to the master node, the slave node will send the offset and master node id to the master node.
4. After the master node verifies, if the data after the offset is in the buffer, send it cuntinue response-indicates that partial replication is possible.
5. The master node sends the data in the buffer to the slave node to ensure the normal state of master-slave replication.
5. Heartbeat
After the master and slave nodes establish replication, they maintain a long connection and send heartbeat commands to each other.
The key mechanism of heartbeat is as follows:
1. Both the middle and slave have a heartbeat detection mechanism, each simulates as the client of the other side to communicate, and the client list command is used to view the replication related client information. The connection status of the master node is flags = M, and the connection status of the slave node is flags = S .
2. By default, the master node sends ping commands to the slave nodes every 10 seconds, and the repl-ping-slave-period can be modified to control the sending frequency.
3. The slave node sends the replconf ack{offset} command in the main thread every second to report its current replication offset to the master node.
4. After receiving the replconf information, the master node judges the timeout time of the slave node. If it exceeds 60 seconds of repl-timeout, it judges that the node is offline.
Note: In order to reduce the master-slave delay, redis master-slave nodes are generally deployed in the same computer room/same-city computer room to avoid heartbeat interruption caused by network partitions caused by network delays.
6. Asynchronous replication
The master node is not only responsible for reading and writing data, but also for synchronizing write commands to the slave nodes. The sending process of the write command is completed asynchronously, which means that the master node returns to the client immediately after processing the write command, and does not wait for the replication of the slave node to complete.
The steps of asynchronous replication are very simple, as follows:
1. The master node accepts the processing command.
2. The master node returns the response result after processing.
3. The modification command is sent to the slave node asynchronously, and the slave node executes the copied command in the main thread.
to sum up
This article mainly analyzes the replication principle of Redis, including the replication process, synchronization between data, full replication process, partial replication process, heartbeat design, asynchronous replication process.
Among them, it can be seen that the synchronization between RDB data is very time-consuming. Therefore, Redis exited the psync command similar to incremental replication in version 2.8. When the Redis master-slave directly encounters a network interruption, full replication will not be performed, but the data will be placed in the buffer (default 1MB). Each maintains the copy offset to determine whether the data in the buffer overflows. If there is no overflow, only the buffer data needs to be sent, and the cost is small. Otherwise, full copy is required. Therefore, it is very important to control the buffer size.