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

This article shows you how to get started with Redis Sentinel Sentinel mode, which is concise and easy to understand. I hope you can get something through the detailed introduction of this article.

Redis sentinel is a high-availability implementation of Redis: fault discovery, automatic failover, configuration center, client notification. It has been available since version 2.6 of Redis, but at that time the mode of this version was unstable, and the Sentinel mode did not stabilize until after version 2.8 of Redis. In a production environment, if you want to use the Sentinel mode of Redis, you will try to use the version of Redis after version 2.8.

Although Sentinel has a separate executable file Redis-sentinel, but in fact it is only a Redis server running in a special mode, you can start Sentinel with the given-sentinel option when starting an ordinary Redis server. Some of Sentinel's design ideas are very similar to zookeeper.

Scheduled tasks for sentinel

There are three important timing tasks in the sentinel mechanism.

Every 10 seconds each sentinel performs info on master and slave

Function:

Found the slave node.

Confirm the master-slave relationship.

Every 2 seconds each sentinel exchanges information (pub/sub) through the channel of the master node

Function:

Communicate with each other to master the information of the nodes and their own information, so that they can perceive the newly added sentinel

> interact through the _ _ sentinel__:hello channel of the master node, and all sentinel subscribe to this channel and publish information to it every 2 seconds

Each sentinel ping other sentinel and master,slave every 1 second

Function:

Heartbeat detection

Subjective referral and objective referral subjective referral

Subjective referral: the "bias" of a single sentinel node against the communication failure of Redis nodes.

This is a subjective referral. Because in a complex network environment, this sentinel is not connected with this master, but what if master is connected with other sentinel? So it is a kind of "prejudice".

This is the third timing you rely on: ping the surrounding sentinel and Redis every second. For slave Redis, you can use this subjective referral because it does not need to fail over, but for master Redis, you must use an objective referral.

Objective offline

Objective offline: all sentinel nodes "reach a consensus" on the failure of master Redis nodes (if more than quorum is unified, quorum can be configured).

This depends on the second timing: every two seconds, the sentinel "talks" (a sentinel can ask the other person if they think a given server has gone offline by sending a SENTINEL is-master-down-by-addr command to another sentinel. )

For the downline of master redis, we must reach a consensus, because when it comes to failover, it is not enough to rely on a sentinel judgment.

Leader election

When the sentinel cluster needs to fail over, the Leader is selected in the cluster to perform the failover operation. Sentinel uses Raft protocol to implement the algorithm of electing Leader between sentinel, but it is not completely consistent with the steps described in this paper. The failover is completed during the operation of the sentinel cluster, and all sentinel will be equal again. Leader is simply a role that occurs in a failover operation.

Election process

After a sentinel identifies the node where the master is objectively offline, the sentinel will first see if it has voted for another sentinel. If it has already voted for another Leader, it will not become a Leader at twice the failover timeout. It is equivalent to a Follower.

If the sentinel has not yet voted, it becomes a Candidate.

As described in the Raft protocol, there are several things that need to be done to become a Candidate,sentinel

3.1 Update the failover status to start

3.2 adding 1 to the current epoch is equivalent to entering a new term. In sentinel, epoch is the term in the Raft protocol.

3.3 the timeout for updating yourself is the random addition of a period of time to the current time, and the random time is the random number of milliseconds within 1 second. Send is-master-down-by-addr commands to other nodes to request a vote. The command will bring its own epoch. Vote for yourself. In sentinel, the way to vote is to change the leader and leader_epoch in your master structure to vote for sentinel and its epoch.

Other sentinel will receive an is-master-down-by-addr command from Candidate. If sentinel's current epoch is the same as the epoch passed to him by Candidate, he has changed the leader and leader_epoch in his master structure to other Candidate, which is equivalent to voting for another Candidate. After voting for another sentinel, you can only be a Follower in the current epoch.

Candidate keeps counting his votes until he finds that more than half of the votes agree with him as Leader and more than its configured quorum (quorum can refer to "redis sentinel Design and implementation"). Sentinel adds quorum over the Raft protocol, and whether such a sentinel can be elected as a Leader depends on the quorum it configures.

If Candidate does not get more than half of the votes and more than its configured quorum within an election time, its own election will be lost.

If you are in an epoch, no Candidate gets more votes. Then after waiting for more than twice the failover timeout, Candidate increases the epoch revote.

If a Candidate gets more than half of the votes and more than the number of votes of its configured quorum, it becomes a Leader.

Unlike the Raft protocol, Leader does not send messages that it is a Leader to other sentinel. After other sentinel waits for Leader to select master from slave, and detects that the new master is working properly, it will remove the objective offline identification, so that it does not need to enter the failover process.

Failover process

When multiple sentinel discovered and confirmed that there was a problem with master

Then a sentinel will be elected as the leader.

Then elect a slave as the master

Inform the rest of the slave who the new master is

Notify the client of a master-slave change

Finally, sentinel waits for the old master to come back to life, and then turns the new master into a slave

So, how do you choose the "right" slave node?

Select the slave node with the highest slave-priority (slave Node priority, artificially configured), return if it exists, and continue if it does not exist.

Secondly, the slave node with the largest replication offset is selected (the most complete copy). If it exists, it will be returned, and if it does not exist, it will continue.

Finally, the slave node with the smallest run_id (the node with the earliest startup) is selected.

The basic principle of achieving high availability on the client

Normal use will not be guaranteed if the client is not aware of it after a failover. Therefore, the steps to achieve high client availability are as follows:

Client gets a collection of sentinel nodes

The client uses the sentinel get-master-addr-by-name master-name api to obtain the corresponding master node information.

The client verifies that the currently acquired "master node" is the real master node in order to prevent changes in the primary node during the failover.

The client maintains contact with the collection of sentinel nodes, that is, subscribes to the relevant channels of the sentinel node to obtain relevant information about the master node at all times.

As can be seen from the above model, the Redis sentinel client only needs to communicate with sentinel to obtain the master node information when initializing and switching the master node, so when designing the client, it is necessary to consider the sentinel node set as a configuration (related node information and changes) discovery service.

Issues that need to be explained

Deploy all nodes of Redis sentinel on different physical machines and on the same network as much as possible

The number of sentinel nodes in Redis sentinel should be greater than or equal to 3 and preferably odd. (a large number of nodes can ensure high availability)

A data node in Redis sentinel is no different from a normal data node. Each sentinel node is essentially a Redis instance, but unlike the Redis data node, its main function is to monitor the Redis data node.

When the client initializes, it connects to a collection of sentinel nodes, no longer a specific Redis node, but sentinel is only a configuration center, not a proxy.

The above is how to get started with Redis Sentinel Sentinel mode. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to 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.