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

Most people do not understand the knowledge points of this article "what is the Sentinel failover principle of Redis", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can gain something after reading this article. Let's take a look at this article "what is the Sentinel failover principle of Redis?"

What is a Sentinel?

Sentinel is the high availability solution of redis. The master-slave replication we mentioned earlier is the basis of high availability, but simple master-slave replication requires human intervention to complete the failover. Sentinel can solve this problem. In the case of master-slave replication, when the master node fails, Sentinel can automatically find the fault and complete the failover to achieve real redis high availability. In the Sentinel cluster, the Sentinel monitors the status of all redis servers and other sentinel nodes, finds faults and completes the transfer in time, so as to ensure the high availability of redis.

Construction of Sentinel Cluster

Sentinel is also a redis service in nature, but it provides different functions from ordinary redis services. Sentinel is a distributed architecture, because if you want to ensure the high availability of redis, you first need to ensure your own high availability, so if we need to build sentinels, we need to deploy at least three instances, preferably an odd number, because voting will be involved in subsequent failover.

We can download the Sentinel configuration file under redis's GitHub project. There is a file called sentinel.conf under the project, which can be used as our Sentinel configuration template. Of course, you can also use the redis.conf configuration file, just add the Sentinel-related configuration.

There are not many Sentinel related configuration items, mainly the following configuration items:

/ / Port number, default is redis instance + 20000, so let's just follow this rule: port 26379 / / whether the daemon runs daemonize yes / / the location where the log is stored. This is very important. Through the log, you can view the failover process logfile "26379.log" / / monitor a redis master server named mymaster (custom). The IP address of this master server is 127.0.0.1. The port number is 6379, and / / the last 2 means that at least two sentinels think that the primary server fails before they fail, otherwise the primary service is determined not to fail sentinel monitor mymaster 127.0.0.1 6379 2 / / the Sentinel judges the response time of the server failure, beyond this time no response is received from the server It is considered that after the failure of the server sentinel down-after-milliseconds mymaster 30000 / / after the completion of the failover, the maximum number of slave servers can initiate data replication at the same time. The smaller the number, the longer the time it takes to complete all slave service data replication / / the greater the number, the greater the pressure on the master server sentinel parallel-syncs mymaster 1 / / failover timeout sentinel failover-timeout mymaster 180000

For each Sentinel instance, the configuration items are the same except for port and logfile. After modifying the configuration, we can use the. / redis-sentinel sentinel.conf command to start the sentry, which is similar to the redis instance startup. Because the sentry is also a redis instance, we can use the. / redis-cli-p 26379 info sentinel command to view the current info sentinel information, as shown below:

Sentinel information

Question: how do I find slave servers and other Sentinel when only the master server is configured?

For the discovery of the slave server, Sentinel can obtain the information of the slave server by asking the master server. For discovering other Sentinel nodes, it can be realized by publishing and subscribing, and by sending information to the channel sentinel:hello. There are two main steps:

1. Every 2 seconds, each Sentinel sends a message to the sentinel:hello channels of all master services and slave servers through the publish and subscribe function, which contains the IP address, port number and running ID (runid) of the Sentinel.

2. Each Sentinel subscribes to the sentinel:hello channels of all the master and slave servers it monitors, looking for sentinel (looking for unknown sentinels) that has not appeared before. When a Sentinel finds a new Sentinel, it adds the new Sentinel to a list that holds all other Sentinel known to Sentinel and monitoring the same master server

Principle of Sentinel failover

Failover is the main work of the Sentinel, and the implementation logic behind this is also very complex. Please see the relevant books for the specific implementation logic. I have summed up the following three points about the Sentinel's failover:

1. Listen to the server

Every second, each Sentinel node sends ping commands to master node, slave node and other Sentinel nodes to do heartbeat detection to judge the state of the server.

The node also responds to the Sentinel accordingly. Among these responses, the following three types of responses are valid:

Return + PONG

Return-LOADING

Return-MASTERDOWN

If the node does not reply even once within the value of the master-down-after-milliseconds option set by the Sentinel profile, then Sentinel will mark the server as offline, which is called subjective offline, that is, only this sentinel thinks that the server is offline.

If the server that is subjectively offline is the primary server, in order to confirm whether the primary server is really offline, the Sentinel will ask other Sentinel who are also monitoring the primary server to see if they also think that the primary server has entered the offline state. When enough Sentinel think that the primary server is offline, the Sentinel will judge the primary server as objective offline, which is really offline. And it will be failed over.

2. Select Sentinel nodes to complete the transfer task

Failover is not done jointly by all sentinel, but by electing a sentinel node as the leader to complete the failover, so when the primary server is marked as objective offline, the sentinel will elect a leader through the Raft algorithm to complete the failover work. The rules and methods for redis to elect the leader sentinel are roughly as follows:

All online sentinel are eligible to be selected as leaders, which means that every sentinel has a chance to become a leader.

When sentinel marks the primary server as subjectively offline, it sends a sentinel is-master-down-by-addr command to other Sentinel nodes to set itself as the leader

The Sentinel node that receives the command adopts the first-come-first-served rule. If it has not agreed to the sentinel is-master-down-by-addr command of other Sentinel nodes, it will agree to the request, otherwise it will refuse.

If the Sentinel node finds that it has more than half of the votes, it will become the leader.

If no sentinel leader is elected within a specified period of time, the sentinel leader will be re-elected after a certain period of time until the sentinel leader is elected.

3. Elect a new master server to complete the failover

The elected sentinel leader will complete the rest of the failover, which has three main steps:

(1) pick out a new master server

Among all the slave servers of the offline master server, select a slave server and convert it to the master server. The rules for selecting a new master server are as follows:

Among the slave servers under the failed master server, those that are marked as subjectively offline, disconnected, or whose last reply to the PING command takes more than five seconds will be eliminated.

Among the slave servers under the failed master server, those slave servers that have been disconnected from the failed master server for more than ten times the time specified by the down-after option will be eliminated.

Among the slave servers left after the above two rounds of elimination, the slave server with the largest replication offset (replication offset) is selected as the new master server; if the replication offset is not available or the replication offset of the slave server is the same, then the slave server with the minimum running ID becomes the new master server

Execute the slaveof no one command on the selected slave server to make it the master node.

(2) modify other replication targets of the slave server

When the new master server appears, the next step for the sentinel leader is to ask other slave servers to copy the new master server by sending slaveof new_master port commands to other slave servers. The replication rules are related to the parallel-syncs parameter of the configuration file.

(3) change the old master server into a slave server

The last thing the failover operation needs to do is to set the offline master server as the slave server of the new master service, keep an eye on it, and order it to replicate the new master node when it recovers.

The above is the content of this article on "what is the Sentinel failover principle of Redis". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

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.