1. Addition and deletion of sentinel nodes
Add sentinel, it will automatically find
Steps to remove sentinel
(1) Stop the sentinel process
(2) SENTINEL RESET *, execute on all sentinels, clean up all master status
(3) SENTINEL MASTER mastername, execute on all sentinels, check whether all sentinel pairs have reached agreement on the number
2. The permanent offline of the slave
Let the master remove a slave that has gone offline: SENTINEL RESET mastername and execute it on all sentries
3. Slave switch to Master priority
Slave-> master election priority: slave-priority, the smaller the value, the higher the priority
4. Security certification based on sentinel cluster architecture
Each slave may be switched to master, so each instance must be configured with two instructions
Enable security authentication on the
master , requirepass master connection password, masterauth
sentinel auth-pass <master-group-name> <pass>
5. Disaster recovery drill
Look at the current master through the sentry: SENTINEL get-master-addr-by-name mymaster
Kill -9 off the master node and delete the pid file
Check the sentinel logs to see if the word + sdown appears to identify the master's downtime problem; then the word + odown appears, which is the specified number of quorum sentinels, and all think that the master is down
(1) The three sentinel processes all think that the master is down
(2) The sentinel processes that exceed the quorum designation all think that it is down, and they become odown.
(3) Sentinel 1 is the sentinel who is elected to perform the subsequent master-slave switch
(4) Sentinel 1 went to the new master (slave) and got a new config version
(5) tried to execute failover
(6) voted to elect a slave zone to switch to master, every poll sentry will execute a vote
(7) to make salve , Slaveof noone, do not allow it to be a slave of any node; promote slave to master; the old master thinks that it is no longer a master
(8) The sentry automatically thinks that the previous 187: 6379 has become a slave, 19: 6379 became a master.
(9) The sentinel went to explore the status of the salve 187: 6379 and thought it was down.
All sentinels elected one to perform the master-slave switch operation
If the majority of the sentry is alive, then the main and standby switching operations will be performed
Look at the master through the sentry again: SENTINEL get-master-addr-by-name mymaster
Try to connect to the new master
The fault is recovered, and then restart the old master to see if it is automatically switched to the slave node by the sentry
(1) Manually kill the master
(2) Whether the sentry can perform the master-standby switch and switch the slave to master
(3) After the sentry completes the master-standby switch, can the new master be used
(4) Recover from the failure and reset the old master Start
(5) Whether the sentry can automatically change the old master into a slave and attach it to the new master, and it can also be used
6. Production environment deployment of sentinels
daemonize yes
logfile /var/log/sentinel/5000/sentinel.log
mkdir -p /var/log/sentinel/5000