Redis Master-Slave Synchronization (replication) detailed

Replication

Redis supports a simple and easy-to-use master-slave replication (Master-slave replication) feature that allows the slave server (slave server) to be an exact replica of the master server.
Here are a few important aspects of the Redis replication feature:
Redis uses asynchronous replication. Starting with Redis 2.8, the processing progress of the replication stream (replication stream) is reported to the primary server at the frequency of every second from the server.
A primary server can have multiple slave servers.
Not only the master server can have from the server, from the server can also have its own from the server, multiple from the server can form a graph structure.
The replication feature does not block the primary server: even if one or more of the primary synchronizations are in progress from the server, the master server can continue to process command requests.
Replication does not block from the server: As long as the appropriate settings are in the redis.conf file, the server can also use the old version of the dataset to process the command query, even if the server is in the initial synchronization.
However, the connection request is blocked during the time that the old version dataset was deleted from the server and loaded into the new version dataset.
You can also configure the slave server to send an error to the client when the connection to the primary server disconnects.
Replication can be used solely for data redundancy, or it can improve extensibility by having multiple requests for read-only commands from the server (scalability): For example, a heavy SORT command can be handed to a subordinate node to run.
The primary server can be protected from persistent operations by replicating: Simply turn off the persistence of the primary server and then perform the persistence operation from the server. how the replication function works

Whether the connection is initial or reconnection, a SYNC command is sent from the server to the primary server when a slave server is established. The
master server that receives the SYNC command starts execution of BGSAVE and saves all newly executed write commands to a buffer during the save operation execution.
When BGSAVE finishes executing, the master server sends the. rdb file from the server, receives the. rdb file from the server, and loads the data in the file into memory.
After the master server is in the format of the Redis command protocol, all content accumulated in the Write command buffer is sent to the slave server.
You can personally verify the synchronization process by using the Telnet command: First connect the Redis server that is processing the command request, and then send it the Sync command, and after a while you will see that the Telnet session (session) received a large segment of the data sent by the server (. Rd b file), and then you will see that all the write commands executed by the server are resent to the Telnet session.
Even if multiple slave servers simultaneously send sync to the primary server, the primary server can handle all of these synchronization requests from the server by simply executing the BGSAVE command once.
The server can be automatically re-connected when the connection between the master and slave servers is disconnected, and before the Redis 2.8 release, the re-attached slave server will always perform a full resynchronization operation, starting with the Redis 2.8 version, from The server can choose to perform a full resynchronization or partial resynchronization (partial resynchronization) based on the situation of the primary server. partially re-sync

Starting with Redis 2.8, after the transient failure of the network connection, the master-slave server can attempt to continue with the original replication process (process) without necessarily performing a full resynchronization operation.
This feature requires the primary server to create a memory buffer (in-memory backlog) for the sent replication stream, and a copy offset (replication offset) and a primary server ID (master run) are recorded between the primary server and all slave servers ID), when a network connection disconnects, the slave server is reconnected and requests to the primary server to continue with the original replication process:
If the primary server ID that is logged from the server is the same as the ID of the primary server that is currently being connected, and the data specified by the offset from the server is still stored in the replication stream buffer of the primary server, the primary server sends the missing portion of the data to the server when it is disconnected, and the copy work can continue.
Otherwise, a full resynchronization operation will be performed from the server.
This partial resynchronization feature of Redis 2.8 uses a new PSYNC internal command, and the previous version of Redis 2.8 has only the SYNC command, however, as long as the slave server is a Redis 2.8 or more version, it will depend on the version of the master server to determine whether to use the PSYNC or SYNC:
If the primary server is Redis 2.8 or later, use the PSYNC command from the server to synchronize.
If the primary server is a previous version of Redis 2.8, use the Sync command from the server to synchronize. Configuration

Configuring a Slave server is as simple as adding the following line to the configuration file:

Slaveof 192.168.1.1 6379

Of course, you need to replace the 192.168.1.1 and 6379 in your code with the IP and port number of your home server.
Another way is to call the slaveof command, enter the IP and port of the primary server, and then sync will start:

127.0.0.1:6379> slaveof 192.168.1.1 10086
OK

read-only slave server

Starting with Redis 2.6, read-only mode is supported from the server, and this mode is the default mode from the server.
Read-only mode is controlled by the slave-read-only option in the redis.conf file, or it can be turned on or off via the CONFIG SET command.
Read-only from the server will refuse to execute any write commands, so there will be no case of accidentally writing data to the slave server because of an operation error.
Managed commands such as DEBUG and CONFIG are still available even if the server is read-only, so we should not expose the server to the Internet or any non-trusted network. However, using the command renaming option in redis.conf, we can increase the security of read-only slave servers by prohibiting the execution of certain commands.
You might be curious, since the write data from the server will be overwritten by the resynchronization data, or it may be lost when restarting from the server, so why make one from the server writable.
The reason is that some of the temporary data that is not important can still be saved on top of the server. For example, the client can save the accessibility (reachability) information of the primary server from the server to implement a failover (failover) policy. from server-related configuration

If the master server has a password set through the Requirepass option, we must also make the appropriate authentication settings for the slave server in order for the synchronization operation to proceed smoothly.
For a running server, you can use the client to enter the following command:

Config set Masterauth <password>

To permanently set this password, you can add it to the configuration file:

Masterauth <password>

There are also several options, which are related to the replication stream buffers used when the primary server performs partial resynchronization, and detailed information can refer to the Redis.conf sample files that are included with the Redis source code. The primary server performs a write operation at least n slave servers

Starting with Redis 2.8, to ensure data security, you can configure the primary server to execute the write command only if there are at least N currently connected from the server.
However, because Redis uses asynchronous replication, the write data sent by the primary server is not necessarily received from the server, so the likelihood of data loss is still there.
Here's how this feature works:
Pings the primary server once per second from the server and reports on the processing of the replication stream.
The primary server logs the last time that each PING was sent to it from the server.
The user can configure, specify the maximum value of the network delay Min-slaves-max-lag, and the minimum number of min-slaves-to-write required to perform a write operation from the server.
If there are at least min-slaves-to-write from the server, and the latency values for these servers are less than min-slaves-max-lag seconds, the primary server performs a write operation to the client request.
You can consider this feature as a conditional relaxed version of C in the CAP theory: Although the persistence of the write operation is not guaranteed, at least the window that loses the data is strictly limited to the specified number of seconds.
On the other hand, if the condition does not reach the conditions specified by Min-slaves-to-write and Min-slaves-max-lag, then the write operation will not be executed, and the primary server will return an error to the client requesting the write operation.
Here are two options for this feature and the parameters they require:
Min-slaves-to-write
Min-slaves-max-lag
For detailed information, refer to the Redis.conf sample file that is included with the Redis source code.