Shulou(Shulou.com)05/31 Report--

Redis single machine master-slave high availability optimization is what, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Redis is a high-performance in-memory database. This article focuses on describing some problems encountered by redis in master-slave mode and how to tune them, especially some special problems encountered in cloud environment. As for how to use redis and data structure, Baidu can have a lot of information on the Internet.

Principal node

In a non-clustered environment, redis master-slave mode is used to ensure high availability of business. Therefore, in this mode, both reads and writes are on the host. To ensure high performance of the host, there must be as few IO operations on the host as possible while taking into account the frequent fullsync caused by network-induced master-slave disconnection. Therefore, the key points of optimization for the host are as follows:

Close the primary node aof

Shutting down the primary aof is relatively simple. You can close it with the following command and execute it on the primary node.

Config set appendonly no

Close the primary node save

The reason for shutting down save on the master is to avoid business fluctuations caused by bgsave caused by save rules. Bgsave consumes performance very much. The default save rules of redis are "9001", "30010", "60 10000". Under this rule, a large number of writes will lead to frequent bgsave of the host, resulting in a sharp decline in performance. You can order config set save to shut down the bgsave triggered by writing on the host, and the integrity of the data is handed over to the standby computer for completion. Even so, bgsave cannot be completely eliminated, and bgsave will still be triggered when the slave is first connected or disconnected for too long.

The problem of inconsistent number of key after master-slave synchronization

Because redis only performs regular key elimination on the master and commands are propagated to the slave, in the case of a large number of key and many key with expiration time, the problem of the elimination mechanism will lead to the discrepancy between the number of key of the master and slave after synchronization and the number of key of the host (expired key will not be synchronized to the slave), and the most fundamental reason is that the host will only phase out 20 key by default when it is eliminated in the serverCron function. The default value is # define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 / * Loopkups per loop in redis.h. * / definition, the first way to solve this problem is to modify the number of recompilations, but to modify the hz attribute in redis.conf to speed up the frequency of serverCron execution.

Frequent fullsync problem caused by master-slave disconnection due to full send buffer

Redis maintains a send buffer for the client of each link, and limits the size (soft and hard). When the send buffer is full (more than the set value), redis will break the link to achieve self-protection, but problems also arise. When the amount of writing is very large and the setting of this value is unreasonable, it will lead to frequent disconnection between the master and slave. And because the slave connected to the new connection cannot perform partial synchronization, the full synchronization can be triggered. In order to avoid this problem, the parameter client-output-buffer-limit can be modified according to the actual data written by redis and the network conditions. The specific amount of modification depends on the actual write volume and network conditions. The setting method is as follows:

Config set client-output-buffer-limit "slave 4295000768 4295000768 0"

Slave means slave link, ordinary client is normal, publish and subscribe client is: pubsub

Copy backlog buffer repl-backlog-size

The copy backlog buffer caches the most recent write command and is created when there is a slave link. The size of the buffer defaults to 1m. The change determines whether the slave is fully or partially synchronized after re-linking. If the copy offset is partially synchronized in the replication backlog buffer, it is less than or larger than the replication backlog buffer, then full synchronization is done. You can reset repl-backlog-size through the config set command according to the actual situation.

Node life or death judgment

In the high availability system, the life and death check of the node is very important, the detection logic should quickly find the problem and switch quickly, and the detection means are multiple and diverse. The redis detection node is carried out by the way of process detection plus service ping, process detection is to confirm the existence of the target process, but the existence of the target process does not necessarily confirm that the service is available, so add a way to ping to specify the service node. In the course of practical use, it is found that some nodes will switch strangely, and the memory, network, and IO of the machine are all very low, except that some CPU cores are full at the time of switching, and then analyzing the slowlog of the switching node, it is found that the user submitted a query that took up to several minutes at that point in time, because redis was single-threaded, and the ping timeout caused by a time-consuming command led to the switch. The optimization logic is to appropriately increase the time consuming of ping and the number of ping, and there should be a trade-off in this process, that is, the problem should be found quickly and the switch should not be misjudged because of the high time-consuming command.

From the node

The slave node is mainly used to ensure data security, and quickly recover to the master node and provide services after the master node dies. As a slave node, you need to open rdb and aof, and put the user's rdb into the cold backup center according to a certain time rule.

After promoting the primary node, the relevant settings should be restored to the same configuration as the primary node immediately.

After reading the above, have you mastered the method of Redis stand-alone master-slave high availability optimization? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.