table of Contents
I. Introduction
Why use sentinels?
Sentinel is mainly to solve the situation of downtime in the master-slave replication architecture, which is mainly divided into two situations:
- Slave Redis downtime: This is relatively simple. After the slave library restarts in Redis, it will be automatically added to the master-slave architecture to automatically synchronize data. After Redis 2.8 version, incremental replication is realized when the master and slave are restored after disconnection.
- Master Redis downtime: This is relatively more complicated and requires the following 2 steps to complete
(1) The first step is to execute the SLAVEOF NO ONE command in the slave database, disconnect the master-slave relationship and promote the master database to continue serving;
(2) In the second step, after restarting the main library, execute the SLAVEOF command to set it as the slave library of other libraries, then the data can be updated back.
Since this manual recovery process is actually cumbersome and error-prone, the sentinel function provided by Redis solves the problem.
2. Introduction to Sentinel
Sentinel (hereinafter collectively referred to as sentinel) is an officially recommended high-availability (HA) solution. In the previous article, the master-slave high-availability solution of redis was introduced. The disadvantage of this solution is that when the master fails, manual failure recovery is required, while sentinel is an independent process that can monitor one or more masters. From the cluster, it can automatically failover when the master fails. More ideally, sentinel itself is a distributed system. Its distributed design idea is somewhat similar to zookeeper. When the master fails at some point, the sentinel cluster uses the Raft algorithm To select the Leader, the failover is completed by the Leader. For the client, to operate the master node of redis, we only need to ask sentinel, and sentinel returns the currently available master, so that the client does not need to pay attention to the switch caused by the client configuration changes. A typical sentinel architecture is shown below:
The main functions of sentinel:
- Monitoring: sentinel will constantly check whether the Master and Slave are operating normally.
- Notification: When there is a problem with a monitored Redis instance, sentinel can send notifications to administrators or other applications through the API.
- Automatic failover (Automatic failover): When a Master fails to work normally, sentinel will start an automatic failover operation. It will upgrade one of the slaves of the failed Master to the new Master, and change the other slaves of the failed Master to Copy the new Master; when the client tries to connect to the failed Master, the cluster will also return the address of the new Master to the client, so that the cluster can use the Master instead of the failed Master.
- Configuration provider: If a failover occurs, sentinel will return the new master address.