Redis command reference Replication)

Redis command reference Replication)

Redis supports the simple and easy-to-use master-slave replication function, which enables the slave server to become a precise replica of the master server.

The following are several important aspects of the Redis replication function:

Redis uses asynchronous replication. Starting from Redis 2.8, the slave server will report the replication stream processing progress to the master server at a frequency every second.

A primary server can have multiple slave servers.

Not only can the master server have a slave server, but also the slave server can have its own slave server. A graph structure can be formed between multiple slave servers.

The replication function does not block the master server. Even if one or more slave servers are performing initial synchronization, the master server can continue to process command requests.

The replication function does not block the slave server as long as it is in redis. the conf file is configured accordingly. Even if the slave server is synchronizing data for the first time, the server can use the old version of the dataset to process command queries.

However, connection requests will be blocked during the time when the old version of the dataset is deleted from the server and the new version of the dataset is loaded.

You can also configure the slave server to send an error to the client when it is disconnected from the master server.

The replication function can be simply used for data redundancy, or it can improve scalability by allowing multiple slave servers to process read-only command requests: for example, the heavy SORT command can be handed over to the secondary node for running.

The replication function can be used to prevent the master server from performing persistence operations: you only need to disable the persistence function of the master server and then perform the persistence operation on the slave server.

How replication works
Whether it is a first connection or a new connection, when a slave server is established, the slave server will send a SYNC command to the master server.

The master server that receives the SYNC command will start to execute BGSAVE and save all newly executed write commands to a buffer zone during the execution of the Save operation.

After BGSAVE is completed, the master server sends the. rdb file obtained from the save operation to the slave server, receives the. rdb file from the server, and loads the data in the file into the memory.

Then, the master server sends all the content accumulated in the write command buffer to the slave server in the format of the Redis command protocol.

You can use the telnet command to verify the synchronization process: first, connect to a Redis server that is processing the command request, and then send the SYNC command to it. After a while, you will see that the telnet session receives a large data segment from the server (. rdb file), and then you will see that all the write commands executed on the server will be re-sent to the telnet session.

Even if multiple slave servers send SYNC requests to the master server at the same time, the master server only needs to execute the BGSAVE command once to process all these slave server synchronization requests.

The slave server can automatically reconnect when the Master/Slave servers are disconnected. Before Redis 2.8, full resynchronization is always performed on the slave server after the disconnection) but starting from Redis 2.8, the slave server can choose whether to perform full or partial Synchronization Based on the master server ).

Partial re-synchronization
Starting from Redis 2.8, after transient network connection failure, the Master/Slave server can try to continue executing the original replication process (process), instead of performing the full re-synchronization operation.

This feature requires the master server to create a memory buffer (in-memory backlog) for the sent replication stream, and a replication offset (replication offset) is recorded between the master server and all slave servers) when a network connection is disconnected with a master server ID (master run id), the slave server will reconnect and request the master server to continue executing the original replication process:

If the master server ID recorded by the slave server is the same as the ID of the master server to be connected, and the data specified by the offset of the slave server record is still saved in the master server's copy stream buffer, the master server will send the part of the data missing when the disconnection occurs to the slave server, and then the replication can continue.
Otherwise, the slave server needs to perform the full re-synchronization operation.
This part of the resynchronization feature of Redis 2.8 uses a new internal PSYNC command. The earlier version of Redis 2.8 only has the SYNC command. However, as long as the slave server is Redis 2.8 or later, it will decide whether to use PSYNC or SYNC Based on the master server version:

If the master server is Redis 2.8 or later, the slave server uses the PSYNC command for synchronization.
If the master server is a version earlier than Redis 2.8, the slave server uses the SYNC command for synchronization.
Configuration
It is very easy to configure an slave server. You only need to add the following line to the configuration file:

Slaveof 192.168.1.1 6379
Of course, you need to replace 192.168.1.1 and 6379 in the Code with the IP address and port number of your master server.

Another method is to call the SLAVEOF command, enter the IP address and port of the master server, and then the synchronization starts:

127.0.0.1: 6379> SLAVEOF 192.168.1.1 10086
OK
Read-Only slave server
Starting from Redis 2.6, the slave server supports read-only mode, and this mode is the default mode of the slave server.

The read-only mode is controlled by the slave-read-only option in the redis. conf file. You can also use the config set command to enable or disable this mode.

The read-only slave server rejects the execution of any write command, so data is not accidentally written to the slave server due to operation errors.

Even if the slave server is read-only, management commands such as DEBUG and CONFIG can still be used, we should not expose the server to the Internet or any untrusted network. However, using the command rename option in redis. conf, we can disable the execution of some commands to improve the security of the read-only slave server.

You may be curious, since the write data on the slave server will be overwritten by the re-synchronization data, or may be lost when the slave server is restarted, why should a slave server become writable?

The reason is that some unimportant temporary data can still be stored on the slave server. For example, a client can store the accessibility information of the master server on the slave server to implement a failover policy.

Slave Server Configuration
If the master server uses the requirepass option to set a password, in order for the slave server to synchronize smoothly, we must also set the identity for the slave server.

For a running server, enter the following command on the client:

Config set masterauth <password>
To set this password permanently, add it to the configuration file:

Masterauth <password>
There are also several options, which are related to the replication stream buffer used by the master server for partial re-synchronization. For details, refer to the Redis. conf sample file included in the redis source code.

The primary server performs write operations only when there are at least N slave servers ¶
To ensure data security, you can configure the master server to write commands only when at least N slave servers are currently connected to Redis 2.8.

However, because Redis uses asynchronous replication, the write data sent by the master server may not be received by the slave server. Therefore, the possibility of data loss still exists.

The operating principles of this feature are as follows:

The slave server can PING the master server once every second and report the processing status of the replication stream.
The master server records the last PING time that each slave server sends to it.
You can specify the maximum network latency (min-slaves-max-lag) and the minimum number of slave servers required to perform write operations (min-slaves-to-write) by configuring.
If there are at least min-slaves-to-write slave servers, and the latencies of these servers are less Than min-slaves-max-lag seconds, then the master server executes the write operation requested by the client.

You can think of this feature as a relaxed version of C in CAP Theory: although it cannot guarantee the persistence of write operations, at least the window for data loss will be strictly limited to the specified number of seconds.

On the other hand, if the conditions do not meet the conditions specified by min-slaves-to-write and min-slaves-max-lag, the write operation will not be executed, the master server returns an error to the Client Requesting write operations.

The following are two options for this feature and their required parameters:

Min-slaves-to-write <number of slaves>
Min-slaves-max-lag <number of seconds>
For details, refer to the Redis. conf sample file included in the redis source code.

Install and test Redis in Ubuntu 14.04

Redis cluster details

Install Redis in Ubuntu 12.10 (graphic explanation) + Jedis to connect to Redis

Redis series-installation, deployment, and maintenance

Install Redis in CentOS 6.3

Learning notes on Redis installation and deployment

Redis. conf

Redis details: click here
Redis: click here

This article permanently updates the link address: