Redis Sentinel (Sentry Mode)
(1) Configure two instances of redis active and standby
The port numbers are: Master: 6379 Slave: 6381, and start;
For specific configuration, please refer to " Redis Rapid Deployment (Master/Slave) "
(2) Configuring Sentinels
Redis sentinel is actually a special redis instance, which is started using the configuration file sentinel.conf
#1. Port
26379
started by sentinel #2. Specify the master node address, the last number indicates how much sentinel consent is required to execute failover
sentinel monitor master1 127.0.0.1 6379 1
#3. Optional, if redis sets a password, here is also It needs to be set, otherwise sentinel cannot connect to redis
sentinel auth-pass master1 <password> #4. Optional, specify a known slave, if not filled in Sentinel can automatically identify, Sentinel will dynamically modify this sentinel known
during the running process
-slave master1 127.0.0.1 6381
#5. How long to retry after the first heartbeat detection identifies the failure (in milliseconds, retries once per second)
sentinel down-after-milliseconds master1 5000
#6. Optional, for coordination For multiple Sentinels, if there is already a Sentinel for failover, wait for this time and try again. Keep the default of 3 minutes to
send sentinel failover-timeout master1 180000
#7. It is used to coordinate multiple Sentinels, and the number of Sentinels increases every time the failover is performed. , the default count starts from 1.
Sentinel config-epoch master1 1
#8. Optional, other known Sentinels, if not filled in Sentinel can automatically identify
sentinel known-sentinel master1 127.0.0.1 26380 a5ce2add75d868d47ce8e7cae9a744f2c900d67d
#9. How long does the master-slave switch take after the master goes down, the default is 3 minutes, here it is changed to 1 minute
sentinel failover-timeout master1 60000
(3) Start the Sentinel
ui@localhost src]$ ./redis-server ../sentinel.conf --sentinel &
View the currently started redis process:
ui @ localhost src] $ ps -ef | grep 'redis' 500 8337 3880 0 00:07 pts/1 00:00:06 ./redis-server *:26379 [sentinel] 500 8413 3880 0 00:28 pts/1 00:00:01 ./redis-server 127.0.0.1:6379 500 8469 3880 0 00:41 pts/1 00:00:00 ./redis-server 127.0.0.1:6381 500 8485 3940 0 00:44 pts/3 00:00:00 ./redis-cli -p 6381 500 8494 3880 0 00:46 pts / 1 00:00:00 grep redis
(4) Connect to redis through the client to test whether redis is normal
- Connect to Master first, test read and write operations, normal
ui@localhost src]$ ./redis-cli -p 6379 127.0.0.1:6379> set foo 123 OK 127.0.0.1:6379> get foo "123" 127.0.0.1:6379> exit
- Connect to Slave again, test reading and writing, Slave can only read, not write;
ui@localhost src]$ ./redis-cli -p 6381 127.0.0.1:6381> get foo "123" 127.0.0.1:6381> set foo 12333 (error) READONLY You can't write against a read only slave.
(5) Test failover
- We manually kill the Master process
ui@localhost src]$ kill 8413
- Looking at the log output of the sentinel, it is found that the failover has been started, and the original slave is selected as the master, as follows:
8337:X 06 Jul 00:47:54.989 # +sdown master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:54.989 # +odown master master1 127.0.0.1 6379 #quorum 1/1 8337: X 06 Jul 00: 47: 54.989 # + new-epoch 238 8337:X 06 Jul 00:47:54.989 # +try-failover master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.042 # +vote-for-leader a5ce2add75d868d47ce8e7cae9a744f2c900d67d 238 8337:X 06 Jul 00:47:55.042 # +elected-leader master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.042 # +failover-state-select-slave master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.100 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.100 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.172 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.686 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.686 # +failover-state-reconf-slaves master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.693 # +failover-end master master1 127.0.0.1 6379 8337:X 06 Jul 00:47:55.693 # +switch-master master1 127.0.0.1 6379 127.0.0.1 6381 8337:X 06 Jul 00:47:55.693 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master1 127.0.0.1 6381
- Test the read and write of 6381 again. At this time, 6381 has changed from slave to master, so read and write can be executed normally.
127.0.0.1:6381> set foo 12333 (error) READONLY You can't write against a read only slave. 127.0.0.1:6381> get foo "123" 127.0.0.1:6381> set foo 999 OK
- Try to connect to the original master 6379, it has been killed
ui@localhost src]$ ./redis-cli -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused Could not connect to Redis at 127.0.0.1:6379: Connection refused
- After restarting 6379, check the sentinel log output, you can see that 6379 is regarded as the slave of 6381
8337:X 06 Jul 00:54:28.058 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ master1 127.0.0.1 6381 8337:X 06 Jul 00:54:37.995 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master1 127.0.0.1 6381
- Connect to 6379 again for read and write operations, confirming that 6379 has indeed become a slave.
ui@localhost src]$ ./redis-cli -p 6379 127.0.0.1:6379> get foo "999" 127.0.0.1:6379> set foo 1234 (error) READONLY You can't write against a read only slave.
(6) Sentinel log description:
- 1. Subjectively Down (SDOWN for short) refers to the offline judgment made by a single Sentinel instance on the server.
- 2. Objectively Down (ODOWN for short) refers to the server obtained after multiple Sentinel instances make SDOWN judgments on the same server and communicate with each other through the SENTINEL is-master-down-by-addr command Offline judgment.
Remark:
- Objective offline conditions apply only to masters: For any other type of Redis instance, Sentinel does not need to negotiate before determining them as offline, so slaves or other Sentinels will never reach objective offline conditions.
- As long as a Sentinel finds that a master server has entered an objectively offline state, this Sentinel may be elected by other Sentinels and perform automatic failover operations on the failed master server.