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

What is the principle of sentinel in Redis? many novices are not very clear about it. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Sentinel

In a typical one-master and multi-slave Redis system, when the master database encounters an abnormal interruption of service, it is necessary to manually select a slave database to upgrade the master database. The whole process requires manual intervention and is difficult to automate.

Redis2.8 provides Sentinel 2. 0 (2. 6 provides 1. 0, but there are many problems), and Sentinel monitors the health of the Redis system as its name implies. Its functions include the following two:

Monitor whether the master database and slave database are running properly

When the master database fails, the slave database will be automatically upgraded to the master database.

Sentinel is an independent operation, in an one-master and multi-slave Redis system, multiple sentinels can be used to monitor the entire Redis system, and Sentinels will monitor each other.

Configuration

Based on the previous one-master and two-slave architecture, join the Sentinel for them.

You can find the sentinel.conf file in the redis directory of the three redis nodes. This file is the configuration file of Sentinel. Modify the configuration as follows:

Sentinel monitor mymaster 192.168.2.101 6379 3

Where:

Mymaster is the name of the main database to be monitored, which can be customized

Next is the ip and port of the main database

The last 3 means the minimum number of votes passed by the Sentinel.

If you need to start in the background, modify the daemonize parameter:

Daemonize yes

If there is a firewall after configuration, do not forget to open the port of the Sentinel. The default is 26379.

Finally, open the sentinel:

Redis-sentinel / yourpath/sentinel.conf

To do a test, after shutting down the main database (192.168.2.101), wait 30 seconds (default 30 seconds):

The Sentinel will upgrade from a node in the database to the master database (192.168.2.102)

Switch another master database from the database (192.168.2.103) to the new master database (192.168.2.102)

Then start the master database that was just closed (192.168.2.101), and the Sentinel automatically changes it to the slave database.

Principle

1. Monitoring process

After the Sentinel starts, two connections are established to the primary database to be monitored:

A piece of information used to subscribe to the _ _ sentinel__:hello channel to get information about other sentinel nodes

The other is used to periodically send commands such as INFO to the master database to obtain the information of the master database itself.

After establishing a connection to the master database, the Sentinel periodically performs the following three operations:

Every 10 seconds the Sentinel sends INFO commands to the master and slave databases

Every 2 seconds, the Sentinel sends his own information to the master database and the slave database's _ _ sentinel__:hello channel.

Every 1 second the Sentinel sends PING commands to the master and slave databases and other sentinels

The first operation is to send the INFO command, which aims to obtain the information of the master database and the slave database of the master database, so as to realize the automatic discovery of new nodes and establish two connections to the slave database.

The second operation is to subscribe to the _ _ sentinel__:hello channel and send the Sentinel's own information to share its own information with other Sentinels who are also monitoring the database, while also being able to identify whether the Sentinel is a new Sentinel. A link is also established between Sentinel and Sentinel to send PING commands

The third operation is to send the PING command. After finding the slave database and other sentinels, all you need to do is to regularly monitor whether the Redis service stops. The time interval is related to the down-after-milliseconds in the configuration file. When this value is less than 1 second, the sentry will send the PING command every 1 second. When this value is greater than 1 second, the sentry will send the PING command every 1 second.

The configuration method is to add the following in the sentinel.conf file:

Sentinel down-after-milliseconds mymaster 600 # 600ms send a PING

When the down-after-milliseconds is exceeded, if the PING's database does not reply, the Sentinel considers it subjectively offline. Subjective downline can be understood as the current Sentinel thinks that the node is offline.

If the node is the primary database, the Sentinels will further determine whether it needs to be repaired:

The Sentinel will send a SENTINEL is-master-down-by-addr command to ask other Sentinels whether they also think that the primary database is offline. If the quorum parameter is reached, that is, our command when configuring the Sentinel:

Sentinel monitor mymaster 192.168.2.101 6379 3

With the last parameter 3, the Sentinels will assume that the master database is objectively offline and elect a lead Sentinel to initiate a failure recovery to the master-slave system.

two。 Lead Sentinel election

To perform fault recovery, you need to elect a lead sentry. The selection algorithm for the lead sentry is the Raft algorithm, which is as follows:

It is found that the Sentinel node (A node) which is objectively offline in the main database sends a command to each Sentinel node, asking the other party to choose to be the lead Sentinel.

If the target sentinel node has not selected anyone else, it will agree to set An as the lead sentry.

If A finds that more than half of the sentinel nodes with more than quorum parameters agree to select themselves, then A succeeds in becoming the lead Sentinel

When multiple sentinels run at the same time, there is no possibility that any node will be elected, and each node will wait for a random time to re-launch the election until the election is successful.

3. Fault recovery

When the lead Sentinel is selected, one of the selected databases is upgraded to the primary database:

Select the one with the highest priority from all front-line slave databases, and the priority can be set through slave-priority.

If there are multiple slave databases with the same priority, the greater the offset of the replicated command, the more priority (closest to the master database lost by down)

If there are more than one alternative, choose to run the one with a smaller ID (running ID is not repeated)

After selecting the node, the lead Sentinel will send slaveof no one to this node to upgrade his primary database.

Then you want to send a slaveof command from the database to switch the master database.

Finally, update the internal records, update the old master database that has been out of service to the slave database of the new master database, and automatically add it to the master-slave architecture as a slave database when it is replied.

Sentinel deployment

Recommended deployment options for Sentinels:

Deploy a sentinel for each node (whether master or slave)

Make the network environment of each sentinel the same or similar to its corresponding node

Set the value of quorum to NUnip 2pm 1, so that lead Sentinels will be selected for failure recovery only when most of the Sentinels are unified.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.