Shulou(Shulou.com)06/01 Report--

Note: in master-slave deployment mode, you only need to configure Peplication related items for the slave instance, as described below.

1) slaveof

The slave instance needs to be configured to point to the (ip, port) of master.

2) masterauth

If password protection is enabled for the master instance, the configuration item needs to be filled in the startup password of master; if the password is not enabled for master, the configuration item needs to be commented out

3) slave-serve-stale-data

Specifies the action when the connection between slave and master is broken. The default is yes, indicating that slave will continue to answer requests from client, but the data may be out of date (unable to synchronize from master due to a broken connection). If configured as no, except for the "INFO" and "SLAVEOF" commands normally answered by the slave, the other request commands from the client will be answered by "SYNC with master in progress" until the connection between the slave and the master is reestablished or the slave is promoted to master.

4) slave-read-only

Specifies whether slave is read-only and defaults to yes. If configured as no, this means that the slave is writable, but the written content will be deleted after the master-slave synchronization is completed.

5) repl-ping-slave-period

When Redis is deployed in Replication mode, slave sends PING packets to master in a predetermined period (default is 10s). This configuration can change this default period.

6) repl-timeout

Timeouts in two cases are specified by this configuration: 1) Bulk transfer I timeout; O timeout; 2) master data or ping response timeout.

It should be noted that if the default value is changed, the value entered by the user must be greater than the configuration value of repl-ping-slave-period, otherwise timeout will occur frequently when the delay of the master-slave link is high.

7) repl-disable-tcp-nodelay

Specifies whether to disable the NO_DELAY option for socket when synchronizing data to slave. If yes is configured, NO_DELAY is disabled, and the TCP protocol stack merges the sending of small packets, which reduces the number of packets between master and slave nodes and saves bandwidth, but increases the time it takes to synchronize data to slave. If the configuration is no, indicating that NO_DELAY is enabled, the TCP stack does not delay the sending of packets, so the delay of data synchronization is reduced, but more bandwidth is required. In general, it should be configured as no to reduce synchronization latency, but it can be configured as yes when the network load between master and slave nodes is already high.

Note: the NO_DELAY option of socket relates to the congestion control algorithm of the TCP protocol stack-Nagle's Algorithm.

8) slave-priority

Specifies the priority of the slave. In a deployment environment where more than one slave exists, when master goes down, Redis Sentinel will promote the slave with the lowest priority value to master. It is important to note that if the configuration item is 0, the corresponding slave will never be automatically promoted to master by Redis Sentinel.

With regard to Replication, there are a few points to be clear (the following are mainly summarized here):

A. The concept of Replication of Redis is different from that of cluster. If S is the slave of M, M cannot set itself to the slave of S. If S dies, M works properly; conversely, if M dies, S may stop working properly. "possible" is used here because the specific behavior of S is determined by the slave-serve-stale-data in its configuration file.

B assume a total of 2 nodes, M is master,S and slave, if M dies, the reasonable way to deal with it is to promote S to master (through the SLAVE NO ONE command). When the original master M is restored, set M to the slave of S. Of course, the actual approach is not limited to the suggestions here.

c. Suppose that there are three nodes, M is master,S1 and S2 is slave. If M dies, the reasonable way to deal with it is to upgrade one of the slave to master. At the same time, you need to reset the master of the other slave to the new master instance.

Now, a new question arises: how do you know M is dead?

This involves the monitoring of Redis, but fortunately, we can use Redis Sentinel, a tool officially released by Redis, to complete the monitoring task.

The next note explains the use of sentinel and discusses the pitfalls that may be stepped on in practice.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.