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

This article mainly introduces "the principle and Application of Redis Sentinel Mechanism Sentinel". In daily operation, I believe many people have doubts about the principle and application of Redis Sentinel Mechanism Sentinel. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "the principle and application of Redis Sentinel Mechanism Sentinel". Next, please follow the editor to study!

What is the Sentinel Mechanism?

In the master-slave replication mode, after the master server goes down, the slave server cannot be automatically transferred to the master server and can only be failed over manually.

The Sentinel Mechanism (Sentinel) is a high-availability solution for Redis. A Sentinel system consisting of one or more Sentinel instances is used to manage the master server and all connected slave servers. Fault discovery, automatic failover, configuration center and client notification can be realized.

Monitoring: Sentinel will constantly check whether your master server and slave server are working properly

Reminder (Notification): when there is a problem with a monitored Redis server, Sentinel can send a notification to the administrator or other application through API

Automatic failover (Automatic failover): when a master server does not work properly, Sentinel starts an automatic failover operation, which upgrades one of the slaves of the failed master server to the new master server and allows the other slave servers of the failed master server to replicate the new master server When the client tries to connect to the failed primary server, the cluster also returns the address of the new primary server to the client, so that the cluster can use the new primary server instead of the failed server.

Looking at the picture above, we can understand that the Sentinel mechanism is a set of supervision system based on replication, which can fail over in time. So let's first understand how Redis fails to determine and fail over.

Fault determination

Fault diagnosis, that is, the task that Sentinel is doing, when a Sentinel starts, it will periodically perform the following tasks

Each Sentinel process sends a PING command to known master servers, slave servers, and other Sentinel instances at a frequency of once per second

If the time between each instance (instance) and the last valid reply to the PING command exceeds the value specified by the down-after-milliseconds option, the instance will be marked as subjectively offline. A valid reply can be: + PONG,-LOADING, or-MASTERDOWN

If a Master primary server is marked as subjectively offline, then all Sentinel monitoring the primary server will confirm that the primary server is indeed offline at a frequency of once per second.

If there is a sufficient number of Sentinel (at least up to the number specified in the profile) to confirm that a Master master server is subjectively offline within a specified time range, then the primary server is marked as objective offline

In general, each Sentinel sends INFO commands to known master and slave servers every 10 seconds, and when a master server is marked as objective offline, the frequency of sending INFO commands is changed to once per second

If there is not enough Sentinel to allow the primary server to go offline, the objective offline state of the primary server will be removed; when the primary server returns a valid reply to the Sentinel PING command, the subjective offline state of the primary server will be removed

Subjective referral (Subjectively Down,SDOWN) means that a single Sentinel instance makes an offline judgment to the server.

Objective offline (Objectively Down,ODOWN) refers to the server offline judgment obtained after multiple Sentinel instances make a SDOWN judgment on the server and communicate with each other through the SENTINEL is-master-down-by-addr command.

Set up Sentinel for example preparation

I have prepared 3 virtual machines, 1 master and 2 slave Redis servers and 3 Sentinel instances. On the official website, it is recommended to deploy at least three Sentinel instances to ensure robustness. The specific address ports are as follows.

Service ipportRedis (master) 192.168.249.206379Redis192.168.249.216379Redis192.168.249.226379Sentinel192.168.249.2026379Sentinel192.168.249.2126379Sentinel192.168.249.2226379

The configuration of 1 master 2 slave Redis service is as follows. Modify the redis.conf file

# set to the address of the host running daemonize yes# binding in the background, commented out here, open ip connection # bind 127.0.0.0.The password requirepass 123456 can be set on the main service

Add the address information of the master server to the slave server

# set the address of the master server # replicaof replicaof 192.168.249.20 637 setting the password of the master server # masterauth masterauth 123456

The configurations of the three sentinels are all the same. You can copy a copy of sentinel.conf from the installation directory of Redis, and modify it as follows, mainly to configure the address of the master server.

# set to run daemonize yeslogfile "26379.log" in the background # set the address of the primary server. A quorum of 2 means that when 2 or more sentinels think that the primary server is unavailable Before performing the failover operation # sentinel monitor sentinel monitor mymaster 192.168.249.20 "set the server password # sentinel auth-pass sentinel auth-pass mymaster 12345" specifies the number of milliseconds that Sentinel thinks the server has been disconnected # sentinel down-after-milliseconds sentinel down-after-milliseconds mymaster 3000 "specifies the maximum number of slaves that can synchronize the new master server at the same time during the failover, the smaller the number The longer it takes to complete the failover. But the higher the number, the more slave is not available because of replication. # you can set this value to 1 to ensure that only one slave at a time is unable to process command requests # sentinel parallel-syncs sentinel parallel-syncs mymaster requests specify the failover timeout # sentinel failover-timeout sentinel failover-timeout mymaster 180000

Sentinel is available through the publish / subscribe feature of the Redis instance to automatically discover other Sentinel that is also monitoring the master server, and you can obtain other slave server information through the master server, so we only need to configure the address of the master server.

Start

The startup sequence is: master server, slave server, and then three sentinel processes

Start the Redis service

. / redis-server.. / redis.conf

Sentinel is actually a Redis service, which can be regarded as a special mode Redis service. There are two kinds of commands to start.

. / redis-server.. / sentinel.conf-- sentinel./redis-sentinel.. / sentinel.conf

The effect of starting Sentinel in both ways is the same, and the configuration file must be used when starting up and running, because the system needs this file to save the current state so that it can be loaded on restart.

View host status

We can use the client to connect to the Sentinel and use sentinel master to see the status of the primary server it monitors.

$. / redis-cli-h 192.168.249.20-p 26379192.168.249.20 mymaster 26379 > sentinel master mymaster 1) "name" 2) "mymaster" 3) "ip" 4) "192.168.249.20" 5) "port" 6) "6379" 7) "runid" 8) "2a58b746fe9c963e69887efbc877aa3143eb6ec6" 9) "flags" 10) "master" 11) "link-pending-commands" 12) "0" 13) "link-refcount" 14 ) "1" 15) "last-ping-sent" 16) "0" 17) "last-ok-ping-reply" 18) "16719)" last-ping-reply "20)" 16721) "down-after-milliseconds" 22) "30000" 23) "info-refresh" 24) "2941" 25) "role-reported" 26) "master" 27) "role-reported-time" 28) "2006632" 29) "config" -epoch "30)" 0 "31)" num-slaves "32)" 2 "33)" num-other-sentinels "34)" 2 "35)" quorum "36)" 2 "37)" failover-timeout "38)" 180000 "39)" parallel-syncs "40)" 1 "

We see some monitoring information about the main server

Num-slaves is the number of slave servers; number of num-other-sentinels other sentinels; flags is marked as master. When the host is offline, it will become s_down or o_down.

In addition, to view the status of other slave servers and other sentinels, you can use the following command

Sentinel slaves sentinel sentinels failover

We can manually simulate the failover situation when the primary server is down.

To get the address information of the current primary server, the client can use the sentinel get-master-addr-by-name command

192.168.249.20 sentinel get-master-addr-by-name mymaster1) "192.168.249.20" 2) "6379"

You can see that the current primary service address is 192.168.249.20, then we shut down the service manually, or use the following command to let the server sleep for 40 seconds.

$. / redis-cli-h 192.168.249.20-p 6379192.168.249.20 debug sleep 40OK 6379 > auth 123456OK192.168.249.20:6379 > debug sleep 40OK (40.01s)

When we check the address of the main service again at this time, we should be able to see different information.

192.168.249.20 Sentinel 26379 > sentinel get-master-addr-by-name mymaster1) "192.168.249.22" 2) "6379" this is the end of the study on "the principle and application of Redis Sentinel Mechanism Sentinel". I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.