Sentinel is a process independent of redis and does not provide key/value services to the outside world. The name in the redis installation directory is redis-sentinel . It is mainly used to monitor the redis-server process and manage master/slave. If your redis is not running in master/slave mode, you do not need to set sentinel.
- S_DOWN : subjectively down, directly translated as "subjective" failure, that is, the current sentinel instance considers a redis service to be "unavailable".
- O_DOWN : objectively down, directly translated as "objective" failure, that is, multiple sentinel instances think that the master is in the "SDOWN" state, then the master will be in ODOWN at this time, and ODOWN can be simply understood as the master has been determined by the cluster as "unavailable" , will enable failover.
There are two conditions for the election of redis2.8.7, the first is to filter out some nodes by the following conditions
1. Use the following criteria to filter candidate nodes:
1. The slave node status is S_DOWN, O_DOWN, except for DISCONNECTED
2. The latest ping response time should not exceed 5 times the ping interval (if the ping interval is 1 second, the latest response delay should not exceed 5 seconds, and redis sentinel defaults to 1 second)
3. The info_refresh response does not exceed 3 times the interval of info_refresh (the principle is the same as 2, the default for redis sentinel is 10 seconds)
4. The time for the slave node to lose contact with the master node cannot exceed ( (now - master->s_down_since_time) + (master->down_after_period * 10)). The overall meaning is that the slave node is too late to synchronize with the master (such as a newly started node) and should not participate in the election.
5. Slave priority is not equal to 0 (this is specified in the configuration file, the default configuration is 100).
2. From the candidate nodes, select a new master in the following order
1. Lower slave_priority (this is specified in the configuration file, the default configuration is 100)
2. Larger replication offset (offset automatically increases after each slave synchronizes with the master)
3. Smaller runid (each redis instance will have a runid, usually a 40-digit random string, which is set when redis starts, and the repetition probability is very small)
4. If the above conditions are not enough to distinguish a unique node, it will be selected depending on which slave node handles the most commands sent by the previous master.