Redis - sentinel mode

1 sentry mode

(automatic election mode)


The method of master-slave switching technology is: when the master server goes down, we need to manually switch a slave server to the master server, which requires manual intervention, takes a lot of trouble and effort, and will lead to a way of service that can not be recommended for a period of time. More often, we give priority to sentry mode. Redis has officially provided Sentinel architecture since 2.8 to solve this problem.

The automatic version of Mou Chao's usurpation can monitor whether the host fails in the background. If it fails, it will automatically convert from the library to the main library according to the number of votes.

Sentinel mode is a special mode. Firstly, Redis provides sentinel commands. Sentinel is an independent process. As a process, it will run independently. The principle is that the sentinel sends a command and waits for the response of the Redis server, so as to monitor multiple running Redis instances.

Sentinels here have two functions

1 By sending commands, let Redis The server returns to monitor its running status, including master server and slave server.
2 When the sentry detects master If it goes down, it will automatically slave Switch to master,Then notify other slave servers through publish subscribe mode, modify the configuration file, and let them switch hosts.

However, there may be problems when a sentinel process monitors the Redis server. Therefore, we can use multiple sentinels for monitoring. Monitoring will also be carried out among various sentinels, thus forming a multi sentinel mode.

Assuming that the main server goes down, sentry 1 detects this result first, and the system will not fail immediately. Sentry 1 only subjectively thinks that the main server is unavailable, which becomes a subjective offline phenomenon. When the following sentinels also detect that the primary server is unavailable and the number reaches a certain value, a vote will be held between sentinels. The voting result is initiated by a sentinel for "failover". After the switch is successful, each sentinel will switch the host from the server monitored by themselves through the publish and subscribe mode. This process is called objective offline.


Our current state is one master and two slaves
Configure sentinel profile sentinel conf

# sentinel monitor the monitored name host port 1
sentinel montitor myredis  6379 1 

The following number 1 means that the host hangs up. slave votes to see who takes over as the host. The one with the most votes will become the host!

Activate the sentry

If the Master node is disconnected, a server will be randomly selected from the slave at this time! (there is a voting algorithm in it!)

If the master comes back at this time, it can only be merged into the new master as a slave. This is the rule of sentinel mode!

Sentinel cluster is based on master-slave replication mode. It has all the advantages of master-slave configuration
 The master-slave can be switched and the fault can be transferred, so the availability of the system will be better
 Sentinel mode is the upgrade of master-slave mode. It is more robust from manual to automatic!


Redis It's not good. Online capacity expansion is very troublesome once the cluster capacity reaches the upper limit!
The configuration of sentinel mode is actually very troublesome. There are many choices!

Full configuration of sentinel mode

# Example sentinel.conf
# The port on which the sentinel sentinel instance runs is 26379 by default
port 26379
# sentinel's working directory
dir /tmp
# The ip port of the redis master node monitored by sentry sentinel
# The master name can be named by itself. The name of the master node can only be composed of letters A-z, numbers 0-9 and the three characters ". -" form.
# How many sentinel sentinels in the quorum configuration think that the master node is disconnected? Then it is objectively considered that the master node is disconnected
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 6379 2
# When the requirepass foobared authorization password is enabled in the Redis instance, all clients connecting to the Redis instance must provide it
# Set the password of sentinel sentinel connecting master and slave. Note that the same authentication password must be set for master and slave
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# After the specified number of milliseconds, the master node does not respond to the sentinel sentinel. At this time, the sentinel subjectively thinks that the master node goes offline for 30 seconds by default
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# This configuration item specifies the maximum number of slave s that can synchronize the new master at the same time when a failover active / standby switch occurs,
The smaller the number, the better failover The longer it takes,
But if this number is bigger, it means more slave because replication Not available.
You can ensure that there is only one at a time by setting this value to 1 slave Is in a state where the command request cannot be processed.
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# Failover timeout can be used in the following aspects:
#1. The interval between two failover s of the same sentinel to the same master.
#2. When a slave synchronizes data from a wrong master, the time is calculated. Until the slave is corrected to the correct master
 When synchronizing data in.
#3. The time required to cancel an ongoing failover.
#4. During failover, configure the maximum time required for all slaves to point to the new master. But even after this timeout,
slaves Will still be correctly configured to point to master,But don't press parallel-syncs Here comes the configured rule
# The default is three minutes
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
#Configure the script to be executed when an event occurs. You can notify the administrator through the script. For example, send an email notification when the system is not running normally
 Relevant personnel.
#There are the following rules for the running results of scripts:
#If the script returns 1 after execution, the script will be executed again later. The number of repetitions is currently 10 by default
#If the script returns 2 after execution, or a return value higher than 2, the script will not be executed repeatedly.
#If the script is terminated due to receiving the system interrupt signal during execution, the behavior is the same as when the return value is 1.
#The maximum execution time of a script is 60s. If it exceeds this time, the script will be terminated by a SIGKILL signal and then re executed.
#Notification script: when any warning level event occurs in sentinel (such as subjective failure and objective failure of redis instance, etc.),
The script will be called. At this time, the script should be sent by email, SMS And other ways to inform the system administrator about the abnormal operation of the system
 Rest. When calling the script, two parameters will be passed to the script, one is the type of event and the other is the description of event. If sentinel.conf match
 If the script path is configured in the configuration file, you must ensure that the script exists in this path and is executable, otherwise sentinel nothing
 The normal startup of the method is successful.
#Notification script
# shell programming
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/
# Client reconfiguration master node parameter script
# When a master changes due to failover, this script will be called to notify the relevant clients that the master address has been changed
 Changed information.
# The following parameters will be passed to the script when calling the script:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# At present, < state > is always "failover",
# < role > is one of "leader" or "observer".
# The parameters from IP, from port, to IP and to port are used to communicate with the old master and the new master (i.e. the old slave)
# This script should be generic and can be called multiple times, not targeted.
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/ # It is generally provided by the operation and maintenance department

Tags: Redis

Posted by gobbles on Sun, 17 Apr 2022 12:08:19 +0930