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

This article will explain in detail what is the use of the sentinel mode in Redis. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Basic introduction

Sentinel is the high availability (High Availability) solution of Redis:

A sentinel cluster consisting of one or more sentinel instances can monitor one or more master servers and multiple slave servers. [related recommendation: Redis video tutorial]

When the master server enters the offline state, sentinel can upgrade a slave server under the master server to continue to provide services to the master server, thus ensuring the high availability of redis.

Graphic illustration

Steps for building Sentinel mode

1. Copy a sentinel.conf file

Cp sentinel.conf sentinel-26379.confcp sentinel.conf sentinel-26380.confcp sentinel.conf sentinel-26381.conf

2. Related configuration modification

# the port running by the Sentinel sentinel instance defaults to 26379port 2637. Change `daemonize` from `no` to `yes`daemonize yes#. The ip port#master-name of the redis master node monitored by Sentinel sentinel can only be named by the letter Amurz, the number 0-9, and the three characters ".-_". # quorum when these quorum numbers sentinel Sentinel thinks that the master master node is missing, then it objectively considers that the master node has lost # sentinel monitor sentinel monitor master 127.0.0.1 6379 "when the requirepass foobared authorization password is opened in the Redis instance, then all clients connecting to the Redis instance have to provide the password # set the password of the sentry sentinel connection master-slave note that the authentication password must be the same as the master-slave authentication password # sentinel auth-pass sentinel Auth-pass master MySUPER--secret-0123passw0rd# specifies how many milliseconds after the primary node does not answer the Sentinel sentinel. At this time, the Sentinel subjectively thinks that the primary node is offline by default of 30 seconds. This configuration item, changed to 3 seconds # sentinel down-after-milliseconds sentinel down-after-milliseconds master 300 seconds, specifies the maximum number of slave that can synchronize the new master at the same time when the failover master / slave switch occurs. The smaller the number, the longer it takes to complete the failover. But if this number is higher, it means that more slave is not available because of replication. You can ensure that only one slave at a time is unable to process command requests by setting this value to 1. # sentinel parallel-syncs sentinel parallel-syncs master failover timeout failover-timeout can be used in the following aspects: # 1. The interval between two failover of the same sentinel to the same master. # 2. When a slave synchronizes data from an incorrect master to start calculating the time. Until slave is corrected to synchronize data to the correct master. # 3. The time it takes to cancel an ongoing failover. # 4. When failover, the maximum time it takes to configure all slaves to point to the new master. However, even after this timeout, slaves will still be correctly configured to point to master But it doesn't follow the rules configured by parallel-syncs # default is three minutes # sentinel failover-timeout sentinelf ailover-timeout master1 80000docker run-it-- name redis-sentinel2639-v / Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf-v / Users/yujiale/docker/redis/data26379:/data-- network localNetwork-- ip 172.172.0.16-d redis:6.2.6 redis-sentinel / etc/redis/sentinel.conf

3. Start the sentinel Sentinel instance

# start redis-master and redis-slaver

In the redis-master directory. / redis-server redis.conf in the redis-slaver1 directory. / redis-server redis.conf in the redis-slaver2 directory. / redis-server redis.conf

# start redis-sentinel

In the redis-sentinel1 directory. / redis-sentinel sentinel.conf in the redis-sentinel2 directory. / redis-sentinel sentinel.conf in the redis-sentinel3 directory. / redis-sentinel sentinel.conf

4. Check the startup status

Execution process

1. Start and initialize Sentinel

Sentinel is a special Redis server that does not persist.

After the Sentinel instance is started, each Sentinel creates 2 network connections to the primary server.

Command connection: used to send commands to the master server and receive responses

Subscription connection: used to subscribe to the-sentinel-:hello channel of the master server

2. Get the main Master information

By default, Sentinel sends info commands to the monitored master server every 10 seconds to obtain the information of the master server and its subordinate slave servers.

3. Obtain information from salve

When Sentinel discovers that there is a new slave server in the master server, Sentinel also establishes a command connection and subscription connection to the slave server.

After the command connection is established, Sentinel still defaults to once every 10 seconds, sends an info command to the slave server and records the information from the slave server.

4. Send messages to the master server and slave server by subscription

By default, Sentinel sends messages to all monitored master and slave servers on the-sentinel-:hello channel subscribed to every 2s, carrying the information of the Sentinel itself and the master server.

5. Receive channel information from autonomous server and slave server

When Sentinel establishes a subscription connection with the master server or slave server, Sentinel sends the following command to the server through the subscription connection

Subscribe-sentinel-:hello

Sentinel only creates command connections to each other, not subscription connections, because Sentinel can sense the addition of a new Sentinel by subscribing to the master server or slave server, and once the new Sentinel is joined, the mutually aware Sentinel can communicate through the command connection.

6. Detect the subjective offline status.

Sentinel sends PING commands once per second to all instances with which it has established command connections (master server, slave server, and other Sentinel). The instance returns an invalid reply within down-after-milliseconds milliseconds (except + PONG,-LOADING,-MASTERDOWN). If the instance does not reply within down-after-milliseconds milliseconds (timeout), Sentinel will consider the instance subjectively offline (SDown).

7. Check the objective offline status

When a Sentinel judges a master server as a subjective offline

Sentinel sends query commands to all other Sentinel that monitor the primary server at the same time

Mainframe

SENTINEL is-master-down-by-addr

Other Sentinel replies

Determine if they also think the primary server is offline. If a Sentinel instance that reaches the number of quorum in the Sentinel configuration determines that the primary server is subjectively offline, then the primary server will be determined to be objective offline (ODown).

8. Election Leader Sentinel

When a primary server is determined to be objectively offline, all Sentinel monitoring the primary server will select a Leader Sentinel to perform the failover (failover) operation through the election algorithm (raft).

Sentinel election

Raft

Raft protocol is used to solve the consistency problem of distributed systems.

The node described by Raft protocol has three states: Leader, Follower and Candidate.

Term:Raft protocol divides time into Term (term of office), which can be regarded as a kind of "logical time".

Election process

Raft uses heartbeat mechanism to trigger Leader election

After the system starts, all nodes are initialized to Follower,term 0.

If a node receives a RequestVote or AppendEntries, it will maintain its Follower identity.

If the node does not receive the AppendEntries message for a period of time, it will convert the Leader,Follower to Candidate and start running for Leader without finding the Leader within the timeout period of the node.

Add your own term.

Start a new timer.

Vote for yourself.

Send a RequestVote to all other nodes and wait for a reply from the other nodes.

Once converted to Candidate, the node immediately starts the following things:

If a node receives a consent vote from a majority of nodes before the timer expires, it is converted to Leader. At the same time, AppendEntries is sent to all other nodes, informing them that they have become Leader.

Each node can only vote one vote in a term, adopting the first-come-first-served strategy. Candidate said earlier that it has already voted for itself, and Follower will vote for the first node that receives the RequestVote.

The timer of the Raft protocol takes a random timeout, which is the key to the election of Leader.

Within the same term, the node that is converted to Candidate first initiates a vote to get a majority of votes.

Sentinel's leader election process

1. After a Sentinel determines that the master is objectively offline, the Sentinel will first see if he has voted for another Sentinel. If he has already voted for another Leader, he will not become a Leader within a certain period of time.

2. If the Sentinel has not yet voted, it becomes Candidate.

3. There are several things that Sentinel needs to accomplish:

Update the failover status to start

Adding 1 to the current epoch is equivalent to entering a new term, and epoch in Sentinel is the term in the Raft protocol.

Send an is-master-down-by-addr command to other nodes to request a vote. The command will bring its own epoch.

Vote for yourself (leader, leader_epoch)

4. When other sentinels receive this order, they may agree or reject it to become a leader; (by judging epoch)

5. Candidate will keep counting his votes until he finds that more than half of the votes that approve him as Leader and more than its configured quorum, then it becomes Leader.

6. After other Sentinel waits for Leader to select master from slave, and detects that the new master is working properly, the objective offline flag will be removed.

Fail-over

When Leader Sentinel is elected, Leader Sentinel performs a failover operation to the offline primary server

1. It will upgrade one of the Slave of the failed Master to the new Master and change the other Slave of the failed Master to copy the new Master.

two。 When the client tries to connect to the failed Master, the cluster also returns the address of the new Master to the client, allowing the cluster to replace the failed Master with the current Master.

After switching between 3.Master and Slave servers, the contents of Master's redis.conf, Slave's redis.conf and sentinel.conf 's configuration files will be changed accordingly, that is, there will be an extra line of replicaof's configuration in the redis.conf configuration file of the Master master server, and the monitoring target of sentinel.conf will be changed accordingly.

Selection of primary server

1. Filter out nodes that are subjectively offline

two。 Select the node with the highest slave-priority. If it is returned by, then continue to select.

3. Select the department node with the largest replication offset, because the larger the replication offset is, the more complete the data is replicated. If it is returned by, continue without it.

4. Select the node with the smallest run_id, because the smaller the run_id, the fewer restarts.

This is the end of the article on "what is the use of the Sentinel Mode in Redis". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.