1. What is the sentinel mechanism?
A: The sentinel system of Redis is used to manage multiple Redis servers. The system performs the following three tasks:
Monitoring : The sentinel will constantly check whether your Master and Slave are operating normally.
Notification : When there is a problem with a monitored Redis, sentinel can send notifications to administrators or other applications through API.
Automatic failover : When a Master fails to work normally, the sentinel will start an automatic failover operation. It will upgrade one of the slaves of the failed Master to the new Master, and let the other slaves of the failed Master Copy the new Master instead; 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.
Sentinel is a distributed system. You can run multiple sentinel processes in an architecture . These processes use gossip protocols to receive information about whether the Master is offline, and use agreement protocols. ) To decide whether to perform automatic failure migration, and which Slave to choose as the new Master.
Each sentinel will send regular messages to other sentinels, masters, and slaves to confirm whether the other party is "alive". If it is found that the other party has not responded within the specified time (configurable), it is temporarily considered that the other party is dead (The so-called "Subjective Down" Subjective Down, referred to as "sdown").
If most sentinels in the "sentinel group" report that a certain master has not responded, the system considers the master to be "completely dead" (ie: objectively true Down machine, Objective Down, referred to as odown), through a certain vote algorithm, from the remaining slave nodes, select one to promote to the master, and then automatically modify the relevant configuration.
Although sentinel is released as a separate executable file redis-sentinel, it is actually just a Redis server running in a special mode. You can start a normal Redis server by specifying the --sentinel option. Activate the sentinel.
Some of the design ideas of sentinel are very similar to zookeeper
2. Configuration modification of sentinel mode
Implementation steps:
1. Copy to the etc directory
cp sentinel.conf /usr/local/redis/etc
2. Modify the sentinel.conf configuration file
Configure the main server for monitoring, where sentinel monitor stands for monitoring, mymaster stands for the name of the server, which can be customized, ip stands for the main server for monitoring, 6379 stands for port, 2 stands for only two or more sentinels that think the main server is unavailable At that time, the failover operation will be performed.
sentinel monitor mymast 192.168.110.133 6379 2 #Master node name IP port number election times
#Configure the password of the master server (if no password is set, you can omit it) sentinel auth-pass mymaster 123456
3. Modify the heartbeat detection to 5000 milliseconds
sentinel down-after-milliseconds mymaster 5000
4. How many qualified nodes to make
sentinel parallel-syncs mymaster 2
5. Start sentinel mode. /
redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. Stop sentinel mode
note:
1. After starting the sentry mode, if your master server goes down, the sentry will automatically vote for a master master server from the redis server; this master server can also perform read and write operations!
2. If the main server that was down before has been repaired, it can be officially operated. Then this server can only perform read operations and will automatically follow the new server elected by the sentry!
3. You can enter ./redis-cli, enter info, and check your status information;
Three, Sentinel ( Sentinel) summary
1. The role of Sentinel :
A. Master status monitoring
B. If the Master is abnormal, a Master-slave conversion will be performed, and one of the Slaves will be used as the Master, and the previous Master will be used as the Slave
C. After the switch of Master-Slave, the contents of master_redis.conf, slave_redis.conf and sentinel.conf will be changed, that is, there will be an additional line of slaveof configuration in master_redis.conf, and the monitoring target of sentinel.conf will be changed accordingly
2. How Sentinel works :
1): Each Sentinel sends a PING command to the Master, Slave and other Sentinel instances it knows at a frequency of once per second.
2): If an instance (instance) is more than the value specified by the down-after-milliseconds option from the last valid reply to the PING command, the instance will be marked as subjective offline by Sentinel.
3): If a Master is marked as subjectively offline, all Sentinels that are monitoring this Master must confirm that the Master has indeed entered the subjective offline state at a frequency of once per second.
4): When a sufficient number of Sentinel (greater than or equal to the value specified in the configuration file) confirm that the Master has indeed entered the subjective offline state within the specified time range, the Master will be marked as objectively offline.
5): Under normal circumstances, each Sentinel will send an INFO command to all known Masters and Slaves at a frequency of once every 10 seconds.
6): When the Master is marked as objectively offline by Sentinel, the frequency of sending INFO commands by all slaves of the down-line Master by Sentinel will be changed from once every 10 seconds to once every second.
7): If there is not enough Sentinel to agree that the Master has gone offline, the objective offline status of the Master will be removed.
If the Master returns a valid response to the Sentinel's PING command, the subjective offline status of the Master will be removed.
Finally, if you don’t understand, I recommend reading two blogs to understand!
1.http://blog.csdn.net/zbw18297786698/article/details/52891695
2.http://blog.csdn.net/candy_rainbow/article/details/52842402