Redis from entry to abandonment series (9) Sentinel

Redis from entry to abandonment series (9) Sentinel

The example in this article is based on: 5.0.4

As a Redis high-availability solution, Redis Sentinel has functions such as monitoring, notification, and automatic failover. All of this is a major premise of relying on active-standby synchronization (refer to the previous section: Redis from entry to abandonment series (8) Active-standby synchronization).

• Listening: Sentinel will constantly check whether the master node and the replica node are working properly
• Notification: When there is a problem with a node running, it can notify other processes (eg: clients)
• Automatic failover: When the master node is down, Sentinel will enable the failover process, promote the replica node to the master node, other replica nodes reconfigure the new master node, and tell the client which master address needs to be reconnected.

In Internet applications, if the program is only deployed on a single machine, there will be a single point of problem, so how does Sentinel, a Redis high-availability solution, solve this problem?

Welcome to the WeChat public account Black Search, D(black-search)

Start method

• redis-server sentinel configuration file --sentinel
• redis-sentinel sentinel configuration file

Sentinel configuration

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

The above configuration is the minimum configuration for Sentinel.

• sentinel monitor <master-group-name> <ip> <port> <quorm>Listen to port 6379 of the 127.0.0.1 address and name it mymaster. When two Sentinel nodes in the cluster think that the mymaster node is down, it will go offline objectively.

Additional Sentinel Configurations

sentinel <option_name> <master_name> <option_value>

• down-after-milliseconds is in milliseconds. When there is no heartbeat after this time, Sentinel subjectively believes that the node has been shut down. Only when most Sentinels determine that the node has been shut down will failover (ie, objective offline) be started.
• parallel-syncs specifies how many slave servers can synchronize the new master at the same time when performing a failover. The smaller the number, the longer it takes to complete the failover (when failover, each Only this number of replica nodes are allowed to synchronize to the new node, then if there are more replica nodes in the cluster, it will take a longer time, but with more replicas set up, the replica nodes will be unavailable for a short time due to RDB)
• failover-timeout failover timeout
  • Restarting a failover after a previous failover has already been attempted against the same host by a given Sentinel takes twice as long as the failover timeout
  • Use the new replica node as the master node, and force the use of the new master's data backup as the timeout period for the data of other replica nodes
  • The time it takes to cancel a failover that is already in progress without any configuration changes (the new master has not yet synced to the other replicas)
  • Maximum time for an ongoing failover to wait for all replicas to be reconfigured as new master replicas

Subjective offline && objective offline

• Subjective offline: The offline judgment made by a single sentinel program on the server
• Objective offline: Refers to the offline judgment made by more than quorm sentinel programs on the server.

The sentinel program will send the PING command to the redis node. If the redis node does not correctly reply to the sentinel request or does not reply within the specified time, the sentinel program will consider the redis subjective offline.

Valid reply:

• +PONG
• -LOADING
• -MASTERDOWN

The objective offline condition is only applicable to the master node. For other replica nodes, sentinel will go offline if it judges them to be subjective offline. Only the sentinel program that participates in the judgment of objective offline can participate in the failover operation.

When we set up the sentinel cluster program, we do not need to set the configuration information of the sentinel of different nodes in the corresponding configuration file, so how does the sentinel know each other and send messages?

Automatic discovery of sentinel and replica nodes

Sentinel discovers other sentinel programs through the publish/subscribe function, which is achieved by __sentinel__:hellosending information to the channel. The replica node is found by asking the master node to obtain all the information from the server.

• __sentinel__:helloEach sentinel sends a message containing the information of the sentinel to the channel of the master and replica nodes monitored by it at a frequency of once every 2 seconds .
• Each sentinel subscribes to the channel it is listening to, finds the sentinel that does not appear, and adds it to the sentinel list

Build a sentinel cluster

First, make sure that the master-replica master-standby has been set up

1. Copy a sentinel.conf configuration file and modify it to sentinel_26379.conf sentinel_26380.conf sentinel_26381.conf. Modify the following:

//指定端口
port 26379
//设置后台启动
daemonize yes
//设置pidfile
pidfile "/var/run/redis-sentinel_26379.pid"
//设置日志存放地点,方便查看问题
logfile "/var/log/redis-sentinel_26379.log"
//设置监听的master节点
sentinel monitor mymaster 127.0.0.1 6379 2

2. Execute the redis-sentinel sentinel_26379.confconfiguration . Before starting sentinel, you need to prepare the redis master-replica master and backup have been started~

{{o.name}}

{{m.name}}