12. 【Redis主從架構】Redis集羣和哨兵集羣的容災測試
1. 哨兵節點的增加和刪除
1.1 增加sentinal，會自動發現
會基於master-slave的pub/sub機制，進行sentinal的發現
1.2 刪除sentinal
- 停止sentinal進程
- SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態。
- SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致
2. slave的永久下線
讓 master 摘除某個已經下線的 slave：SENTINEL RESET mastername，那麼，在所有的哨兵節點上執行
3. slave切換成master的優先級
slave -> master選舉優先級：slave-priority，值越小優先級越高。
4. 基於哨兵集羣架構的安全認證
每個slave都有可能切換成master，所以每個實例都要配置兩個指令：
master上啓用安全認證：requirepass
master連接口令，masterauth
sentinal, sentinel auth-pass <master-group-name> <pass>
5. 容災演練
- 通過哨兵查看一下當前的master：
SENTINEL get-master-addr-by-name mymaster
- 將master的節點kill掉，pid文件也刪除掉。
- 查看sentinal的日誌，是否出現+sdown字樣，失敗處理master的宕機問題；然後出現+odown字樣，就是指定的quorum哨兵數量，都認爲master宕機了，master就真正的宕機了。
-
三個哨兵進程都認爲master是sdown了。
-
超過quorum指定的哨兵進程都認爲sdown之後，就變爲odown了。
-
哨兵1是被選舉爲要執行後續的主備切換的那個哨兵
-
哨兵1去新的master(slave)獲取一個新的config version
-
嘗試執行failover
-
投票選舉出一個salve區切換成master，每個哨兵都會執行一次投票。
-
讓slave，slaveof noone，不讓它去做任何節點的slave；把slave提拔成master；舊的master認爲不再是master了。
-
哨兵就自動認爲之前的102:6379變成slave，111:6379變成master了。
-
哨兵去彈出以下102:6379這個slave的狀態，認爲他sdown了。
所有哨兵短句出了一個，來執行主備切換操作
如果哨兵的majority都存活着，那就會執行主備切換操作。
再通過哨兵看一下：SENTINEL get-master-addr-by-name mymaster
- 發現mster節點由原來的 192.168.0.103節點變成了 192.168.0.104 節點
嘗試連接以下新的master(192.168.0.104)
故障恢復，在將舊的master重新啓動，查看是否被哨兵啓動切換成slave節點。
- 總結
1. 手動殺掉master
2. 哨兵能否執行主備切換，將slave切換爲master
3. 哨兵完成主備切換後，新的master能否使用
4. 故障恢復，將舊的master啓動。
5. 哨兵能否自動將舊的master變成slave節點掛載到新的master節點上面去，而且也是可以使用的。
6. 哨兵的生產環境部署
daemonize yes
logfile /var/log/sentinal/5000
mkdir -p /var/log/sentinal/5000
參考石衫老師《億級流量》課程筆記。