(1) Sentinel overview
Earlier we talked about the master-slave replication of redis. In order to achieve high availability, one server will be selected as the master and multiple servers as the slaves. Now there is a situation where the master is down. At this time, the system will select a slave as the master, then take the down master offline, and then notify all slaves who the new master is. Here is a question. Who decides whether the master is down and which slave is selected as the master?
In master-slave replication, sentinels complete these operations. The sentinel is a distributed system that monitors each server in the master-slave structure. When a failure occurs, a new master is selected through a voting mechanism.
The sentinel is also a redis server, and the number of sentinels is usually configured as an odd number (to avoid a tie during the campaign).
(2) The role of sentry
1. Monitoring: constantly check whether the master and slave are running normally; master survival detection; master and slave running status detection
2. Notification: When there is a problem with the detected server, send a notification to other sentinels and clients
3. Automatic failover: open the master and slave connection, select a new slave as the master, and connect other slaves to the new master
(3) The working principle of the sentinel
3.1 Monitoring phase
Monitoring is one of the roles of sentinels. Monitoring is to synchronize the status information of each node
1. Get the status of each other sentinel (whether online), through the ping command
2. Get the status of the master, mainly including the runid of the master, detailed information of each slave, etc., through the info command
3. Get the status of all slaves (according to the slave information in the master), mainly including the runid, role, host, offset, etc. of the slave.
When two sentinels obtain the monitoring information of the master or slave respectively, they will exchange data for data synchronization. Similarly, when the third sentinel obtains the monitoring information, it will also synchronize data with the other two sentinels.
3.2 Notification phase
The notification phase is mainly the mutual communication of various sentinels. Assuming that there are three sentinels in a system, when sentinel1 asks about the status of the master and slave servers and gets a reply, he will tell sentinel2 and sentinel3 of his message. Similarly, sentinel2 will tell 1 and 3 when it gets the news. So that the data is always synchronized.
3.3 Failover phase
When a master goes down, it enters the failover phase.
1. First, a sentinel finds that it does not respond to a message to the master, so it sets the status of the master to down and informs other sentinels. Other sentinels will send hello to the master. When more than half of the sentinels (that can be set) feel that the master is down, the status of the master is set to odown, which enters the second step.
2. Now that the master is down, a new master needs to be elected. Which sentinel chooses the master needs to be implemented through the internal voting mechanism of the sentinel. After being elected to execute and find out the sentinel of the new master, proceed to the third step.
3. The sentinel chooses one from the slave as the new master has the following principles
Eliminate the ones that are not online
Eliminate those who have been disconnected for a long time from the original master
Finally, one of the remaining slaves will be selected as the new master based on priority, offset, etc.
4. The sentinel sends instructions to the new master:
slaveof no oneSend instructions to other slaves
slaveof 新masterIP 端口(4) The operation of the sentry
Regarding the operation of the sentinel, it is recommended to operate under the linux server
redis-sentinel sentinel.conf (配置的文件名自定义)-
port 26379 -
dir /tmp -
sentinel monitor mymaster 127.0.0.1 6379 2 -
sentinel down-after-milliseconds 30000 //连接多长时间未响应就认为被监控服务器宕机 -
parallel-syncs mymaster 1 //指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步 -
failover-timeout mymaster 180000 //指定了故障转移的同步超时时间
sentinel monitor mymaster 127.0.0.1 6379 2: 127.0.0.1 6379 represents the object monitored by the sentinel, where mymaster is a name defined by itself, and the last digit 2 means that when two sentinels think that the monitored server is down, they will confirm the The server is down. The value of this one is often the number of sentries/2+1, that is, more than half.
When the host is down, the sentry will automatically select one from the slaves as the host
