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

What is the Redis Sentinel Principle? This problem may be our daily study or work often see. I hope you learned something from this question. The following is the reference content brought to you by Xiaobian. Let's take a look together!

The requested URL/usr/local/redis/was not found on this server.

Let's say a few words first. When we configure master-slave replication, there is a situation where the master node goes down. Who will provide service?

When the master node goes down, master-slave replication has no meaning to exist. In the era when data is king, there is no data to talk about high availability.

At this time, a big brother named sentry appeared out of nowhere. Big brother said,"I'll help you deal with this problem."

Since the master node master as the boss does not lead you to play. I'll pick a boss from the four of you, and you'll play with him.

When the boss who didn't bring you guys to play came back, his identity would be invalid and he wouldn't be your boss anymore. He can only play with the boss I pick.

The above dialogue process is where the meaning of our configuration of sentries is, who plays with whom is who gives data, and we continue to know the role of sentries.

"Finally, let's explain in technical terms what a sentry is."

Sentinel, English name sentinel, is a distributed system used to monitor each server in the master-slave structure, select a new master node through a voting mechanism when the master node fails, and connect all slave nodes to the new master node.

II. Role of sentries

The dialog process we discussed above is one of the roles of sentries automatic failover.

When it comes to function, it definitely means what exactly did this sentry do in his work. Let's start with a more dry concept, and then we'll talk about how it works later.

Three roles of sentries: monitoring, notification, automatic failover

Surveillance. Surveillance. Who? To support the master-slave structure, one is the master node and the other is the slave node, so it must be monitoring these two nodes. Monitor whether the master node and slave node are running normally, detect whether the master node is alive, notify the sentinel of the operation of the master node and slave node, and send a notification to other sentries when there is a problem in the server detected by the sentinel. The sentries are equivalent to a WeChat group, and the problems discovered by each sentinel will be sent to this group. Automatic failover When a master outage is detected, all slave nodes connected to the down master are disconnected, one of the slave nodes is selected as the master node, and the other slave nodes are connected to the latest master node. And inform the client of the latest server address.

One caveat here is that sentinel is also a redis server, but does not provide any services to the outside world.

Configure Sentry to be singular. So why is the number of sentinel servers configured odd? With this question you will find the answer you want below.

2. How to configure sentries 1. preparations

In this chapter, we begin to configure sentries and prepare for preliminary work. Below is the preparation for the click. Open 8 clients, three sentries, one master node, two slave nodes, one master node client and one slave node client.

2. Sentinel. conf configuration interpretation

The configuration file used by sentinels is sentinel.conf Let's interpret the sentinel.conf configuration information

But most of them are comments, and here's a click to give you a command to filter this garbage cat sentinel. conf| grep-v '#'|grep-v '^$'

port 26379: external service port number dir/tmp: stores sentinel monitor mymaster www.example.com6379 2: who is monitored, the name can be customized, the latter 2 represents is, if two sentinels judge that this master node is down, this master node is down, usually set to half the number of sentinels plus one. sentinel down-after-milliseconds mymaster 30000: How long does the sentinel down-after-milliseconds mymaster node not respond to indicate that it is down. The next 30000 is milliseconds, or 30 seconds. sentinel parallel-syncs mymaster1: This configuration item indicates the maximum number of slaves that synchronize with the new master at failover. A lower value means that failover takes longer to complete, and a higher value means that more slaves are unavailable because of synchronized data. sentinel failover-timeout mymaster 180000: How long does synchronization take to complete? The default is 3 minutes. 3. start configuring

Use the command cat sentinel. conf| grep-v '#'|grep-v '^$'>./ data/sentinel-26379.conf Move the filtered information from sentinel. conf to/usr/local/redis/conf and open sentinel-26379.conf to modify the information storage directory

Then make a quick copy of the two sentry profiles, ports 26380 and 26381. sed 's/26379/26381/g' sentinel-26379.conf > sentinel-26381.conf

Test that master-slave replication is in normal working state. Start three redis servers with ports 6379, 6380 and 6381 respectively. Check the master node information. There are two slave nodes connected with ports 6380 and 6381 respectively.

Here is a small dot is lag how one is 1 and one is 0! lag is the delay time, I'm testing locally so there will be 0 cases, using Cloud Virtual Machine is rare. Values of 0 and 1 for lag are normal. Test the master node by adding a hash value, hset kaka name kaka to get kaka values from slave 1 and slave 2 respectively, and check whether master-slave replication works normally.

After testing our master-slave structure is working properly. Start a sentinel redis-sentinel 26379-sentinel. conf to connect to sentinel 26379, mainly in the last line. The master node monitored is named mymaster. The status is normal. There are two slave nodes. The number of sentinels is 1. Check the sentinel configuration information of sentinel 26379. At this time, it has been changed. Start a sentinel of sentinel 26380, redis-sentinel 26380-sentinel. conf. Note that there is one more message in the last line. This id is the new id of our 26379 configuration file. Then we come to the client of sentinel 26379, which is also the id of the new 26380 sentinel. At this time, we check the configuration file of sentinel 26379. The first time we check the configuration file, we do not configure sentinel 26380. The second time we check the configuration file, we add information after configuring sentinel 26380. Finally, we need to start Sentinel Client 3 on port 26381. After startup, our configuration information and server information will also change, adding information that Sentinel 26380 has, and Sentinel 26381 will also have.

Until here, our configuration of the sentinel is over. Next, we put the master node down. After waiting for 30 seconds, we come to the client of 26379 sentinel. Here, some new information is added. So what does this information do? Let us elaborate.

We need to know a few things about this.

+ sdown: After this message, one of the three sentries thinks that the master node is down + odown: This message means that the other two sentries went to connect with the master node and found that the master node was indeed down and then launched a round of voting. Here, the click is using redis4.0. This information varies a bit between versions + switch-master mymaster www.example.com 6379 127.0.0.1 6380: Until here is the result of voting initiated by sentries, redis with port 6380 is selected as the main node + slave slave www.example.com: 6381 127.0.0.1 6381@mymaster 127.0.0.1 6380: Here we make a connection between port 6381 and 6379 and the new master node 6380 + sdown slave www.example.com: 6379 127.0.0.1 6379@mymaster 127.0.0.1 6380: The last sentence is port 6379 or not online, so kick offline

When we put 6379 redis server online again, we can see that the sentry server responded with two sentences. One sentence is to remove the line of 6379. The last sentence is to reconnect 6379 to the new master node. At this time, the master node is 6380. At the redis client setting value of 6380, check whether the master-slave replication works normally.

Add the list type to the new master node 6380 and get this value at 6379 and 6381, so far! Our sentinel mode configuration is complete.

III. Working principle of sentinel

After configuring the sentinel, it is necessary to analyze its working principle. Only by knowing its workflow can we have a better understanding of the sentinel.

This article explains the principle is not so dry! You can read a technical article as a story.

To get to the point, sentinels are used for monitoring, notification, and failover. well, the working principle is also discussed around these three points.

1. Monitor workflow sentinel sends info command and saves all sentinel status. The master node records the information of redis instance. The information recorded by the master node looks the same as the information recorded by sentinel. In fact, it is still a little different. The sentinel will send an info command to the corresponding slave node according to the slave node information obtained at the master node. Then sentinel 2 comes, the same command will be sent to the master node, and the cmd connection will be established. At this time, sentinel 2 will also save the same information as sentinel 1, except that the sentinel information saved is 2. At this point a publish subscription is established between each sentry so that their information is consistent. They also ping each other for long-term symmetry of information between sentries. When there is another Sentinel 3, it does the same thing, sending info to the master and slave nodes. and establish a connection with Sentinel 1 and Sentinel 2. 2. Notification workflow

The Sentinel sends commands to all nodes of the master and slave to get their status, and publishes the information to the Sentinel's subscription.

3. The principle of failover (the focus of this article) The sentinel will continue to send a publish sentinel: hello to the primary node until the sentinel says sdown, which will be a bit familiar. That's right, that's what the sentinel server reported after we disconnected the master node above. After the sentinel reports that the master node is down, it is not finished yet. The sentinel will also publish a message to the intranet indicating that the master node is down. The command sent is sentinel is-master-down-by-address-port. After the rest of the sentinels receive the command, does the master node hang up? Let me see if it's up. The message sent is also hello. The rest of the sentinels will also send what they receive and send the command sentinel is-master-down-by-address-port to their intranet, making sure the first sentinel is-master-down-by-address-port says you're right, this guy is dead. When everyone thinks the master is dead, it changes its state to oown. When a sentinel thinks a master is tagged, it is sdown, and when half of the sentinels think it is tagged, it is odown. This is the reason why the sentries are configured in singular numbers. For one sentinel, it is called subjective offline, and half of the sentries think that the master node is hung, which is called guest offline. Once the guest officer of the master node is considered offline, the sentinel will proceed to the next operation

Now that the sentinel has detected the problem, which sentinel is responsible for selecting the new master node? It can't be Zhang San, Li Si and Wang Wu. This will be chaotic. Therefore, we need to choose the leader among all the sentries. How to choose it? Please see the picture below.

❞

at this time! The five sentinels are meeting together, all the sentinels are on an intranet, and one thing they do is they send the sentinel is-master-down-by-address-port with their campaign count and runid. Each sentinel is both a candidate and a voter. Each sentinel has one vote, and the envelope represents its vote. When sentinel 1 and sentinel 4 send instructions to the group at the same time to prepare for the election, sentinel 2 says that I will vote for whoever receives the instruction first. If sentinel 1 votes early, then sentinel 2 votes for sentinel 1. Voting continues according to this rule until one sentinel has half the votes of the total number of sentinels. Let's say sentinel 1 gets half the votes, and sentinel 1 gets elected. At this point, the next stage is reached. The sentinel above has selected sentinel 1 as the representative to go to all slave nodes to find one as master node. This selection of master nodes is not random. There are certain rules.

Take out the ones that aren't online first.

Sentinel will send messages to all redis, slow response will be killed and the original node disconnected for the longest time to kill, here because the demonstration is not enough, all added a slave 5, no meaning Ha! After the above three points are judged, there are salve 4 and slave 5, which will be screened according to the priority principle.

First of all, according to the priority, if the priority is the same, other judgments are made to determine the offset offset and determine the data synchronization. If the offset of slave 4 is 90 and the offset of slave 5 is 100, then the sentinel will think that there is a problem with the network of slave 4! Slave 5 is chosen as the new master node. The offset of slave 4 and slave 5 is the same. There is also a final judgment. The final step is to judge runid, that is, seniority in the workplace. That is to say, according to the creation time of runid, judge the upper position with the earlier time.

After selecting the new master node, it is necessary to send instructions to all nodes.

IV. Summary

All the knowledge points about sentries have been finished, and the most important thing in this article is the working principle of sentries. Let's briefly explain how it works.

Monitoring is performed first, and all sentries synchronize information

Sentinel posts information to subscribers

failover

The sentinel finds that the master node is offline. The sentinel starts voting for the person in charge. The new master node is selected by the person in charge. The new master node disconnects the original master node, and other slave nodes connect with the new master node. After the original master node is online, it is connected as a slave node.

Thank you for reading! After reading the above content, do you roughly understand what the Redis Sentinel Principle is? I hope the content of this article is helpful to everyone. If you want to know more about related articles, please pay attention to 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.