Redis cluster _ 3. redis master-slave automatic switch Sentinel, redis_3.redis
Redis Sentinel
Sentinel (Sentinel) is a tool used to monitor the Master Status in redis clusters. It has been integrated into redis2.4 + versions.
I. Role of Sentinel:
1): Master status detection
2) If the Master node is abnormal, the Master-Slave switch will be performed, and one of the Slave will be used as the Master node and the previous Master will be used as the Slave.
3) after the Master-Slave switch, master_redis.conf, slave_redis.conf, and sentinel. the content of conf will change, that is, master_redis.conf will have one more slaveof configuration, sentinel. the conf monitoring target will be changed accordingly.
Ii. How Sentinel works:
1): Each Sentinel sends a PING command to the Master, Slave, and other Sentinel instances it knows every second.
2) If the time between an instance and the last valid PING command reply exceeds the value specified by the "down-after-milliseconds" option, this instance is marked as subjective offline by Sentinel.
3): If a Master is marked as a subjective deprecation, all Sentinel of the Master being monitored should confirm that the Master is in the subjective deprecation status once per second.
4): when there is a sufficient number of Sentinel (greater than or equal to the value specified in the configuration file) within the specified time range, it is confirmed that the Master has entered the subjective deprecation status, the Master will be marked as an objective offline
5): In general, each Sentinel sends the INFO command to all known masters every 10 seconds.
6): When the Master is marked as an objective deprecation by Sentinel, the frequency of sending the INFO command from Sentinel to all Slave of the offline Master is changed from 10 seconds to once per second.
7): If there is not enough Sentinel to agree that the Master has been deprecated, the objective deprecation status of the Master will be removed.
If the Master returns a valid reply to the Sentinel PING command again, the Master's subjective offline status will be removed.
Subjective offline and objective offline
Subjective deprecation: Subjectively Down (SDOWN) refers to the deprecation judgment made by the current Sentinel instance on a redis server.
Objective deprecation: Objectively Down (ODOWN) refers to the interaction between multiple Sentinel instances and the SENTINEL is-Master-down-by-addr commands on the master Server, the Master Server goes offline and starts failover.
SDOWNIt is suitable for Master and Slave. As long as a Sentinel finds that the Master enters the ODOWN state, this Sentinel may be selected by other Sentinel instances and automatically perform failover on the active server.
ODOWNIt is only applicable to the Master instance. For Redis instances of Slave, Sentinel does not need to negotiate before judging them as offline, so the Sentinel of Slave will never reach ODOWN.
Iii. Configuration:
1: Listener Master (three nodes)
# Vi/main/redis/sentinel. conf
Port 26379
Daemonize yes
Sentinel monitor mymaster 192.168.100.211 6379 2
Sentinel down-after-milliseconds MySQL master 30000
Sentinel parallel-syncs mymaster 1
Sentinel failover-timeout MySQL master 900000
Logfile "/main/redis/logs/sentinel. log"
# The preceding configuration file is described as follows:
# Specify the sentinel port number in the first line
# Specify sentinel as the background startup in the second line
# Specify Sentinel in Row 3 to monitor a Master named mymaster. the IP address of the Master is 192.168.100.211 and the port number is 6379, the last 2 indicates that when two Sentinel detects a Master exception, the system determines that the Master is invalid. That is, the system automatically migrates the Master only when both Sentinel determine that the Master is invalid, if the number of Sentinel instances is not up to standard, automatic failover is not performed.
# The fourth row specifies the time when Sentinel determines the Master disconnection. (Unit: milliseconds, determined as subjective offline SDOWN)
# The fifth line specifies the maximum number of Slave instances that can be synchronized to the new Master during failover. This number is set to 1. Although it takes longer to complete the Failover, it can ensure that only one Slave is in a state that cannot process command requests.
2: Start sentinel (three nodes ):
#/Main/redis/src/redis-sentinel/main/redis/sentinel. conf
3: Set startup (three nodes)
# Echo "/main/redis/src/redis-sentinel/main/redis/sentinel. conf">/etc/rc. local
4. Notes:
1): the Master must be started first when it is started for the first time.
2): Sentinel only switches from the server, and the app needs to be developed by itself (for example, SentinelJedis of the Jedis library, which can monitor the status of Sentinel)
3) If the Master has been determined to be offline, Sentinel has selected a new Master and changed the old Master to Slave, but it has not been changed to the new Master. If you restart the old Master, the Redis cluster will be in the non-Master state. You can only manually modify the configuration file and restart the cluster.
The redis cluster has been configured.
