15. 哨兵節點管理以及高可用redis集羣的容災演練

哨兵節點管理

增加

增加sentinal，會自動發現，過程參考上一篇14. 【實戰】在項目中重新搭建一套讀寫分離+高可用+多master的redis cluster集羣

刪除

刪除sentinal的步驟

1. 停止master節點 sentinal進程
2. SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
3. SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致

slave的永久下線

讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行

slave切換爲Master的優先級

slave->master選舉優先級：slave-priority，值越小優先級越高

基於哨兵集羣架構下的安全認證

每個slave都有可能切換成master，所以每個實例都要配置兩個指令

1. master上啓用安全認證，requirepass
2. slave連接口令，masterauth

sentinal，sentinel auth-pass <master-group-name> <pass>

容災演練

master發生故障

1. 通過哨兵看一下當前的master：SENTINEL get-master-addr-by-name mymaster
   

2. 把redis master節點 kill -9掉，pid文件也刪除掉
   

3. 查看sentinel的日誌，是否出現+sdown字樣，識別出了master的宕機問題；然後出現+odown客觀宕機，就是指定的quorum哨兵數量都認爲master宕機了。
   

（1）三個哨兵進程都認爲master是sdown了
（2）超過quorum指定的哨兵進程都認爲sdown之後，就變爲odown
（3）哨兵1是被選舉爲要執行後續的主備切換的那個哨兵
（4）哨兵1去新的master（slave）獲取了一個新的config version
（5）嘗試執行failover
（6）投票選舉出一個slave區切換成master，每隔哨兵都會執行一次投票
（7）讓salve，slaveof noone，不讓它去做任何節點的slave了; 把slave提拔成master; 舊的master認爲不再是master了
（8）哨兵就自動認爲之前的 master 192.168.0.106:6379變成了slave了，192.168.0.107:6379變成了master了
（9）哨兵去探查了一下192.168.0.106:6379這個salve的狀態，認爲它sdown了

4. 所有哨兵選舉出了一個slave，來執行主備切換操作，如果哨兵的majority都存活着，那麼就會執行主備切換操作

5. 再通過哨兵看一下原來的master：SENTINEL get-master-addr-by-name mymaster
   

6. 嘗試連接一下新的master，查看redis 信息
   

故障恢復

再將舊的master重新啓動，查看是否被哨兵自動切換成slave節點

總結過程

1. 手動殺掉master
2. 哨兵能否執行主備切換，將slave切換爲master
3. 哨兵完成主備切換後，新的master能否使用
4. 故障恢復，將舊的master重新啓動
5. 哨兵能否自動將舊的master變爲slave，掛接到新的master上面去，而且也是可以使用的

哨兵啓動生產環境配置

1. 之前哨兵啓動的時候，redis-sentinel /etc/sentinal/5000.conf，直接顯示控制檯，ctrl+c會直接殺死進程，這種只適合在測試環境中；
2. 生產環境中配置下面：
   

mkdir -p /var/log/sentinal/5000

daemonize yes 	## 後臺方式啓動
logfile /var/log/sentinal/5000/sentinal.log