一、首先配置redis的主從同步集群。 1、主庫的配置文件不用修改，從庫的配置文件只需增加一行，說明主庫的IP埠。如果需要驗證的，也要加多一行，認證密碼。 slaveof 192.168.20.26 5268 masterauth hodge01 一主多從的話，就啟用多個從庫。其中，從庫都是一樣的 ...
一、首先配置redis的主從同步集群。 1、主庫的配置文件不用修改，從庫的配置文件只需增加一行，說明主庫的IP埠。如果需要驗證的，也要加多一行，認證密碼。 slaveof 192.168.20.26 5268 masterauth hodge01
一主多從的話，就啟用多個從庫。其中，從庫都是一樣的方案。本次有兩個slave。 2、命令檢查。 /usr/local/redis/bin/redis-cli -p 5257 -a hodge01 info Replication
二、sentinel高可用。 1、概況。sentinel是redis自帶的附件，在新的版本redis安裝都有sentinel。sentinel是稱作哨兵的監控機制，當達到一定數量的sentinel投票支持，redis的master就會切換。本次使用docker容器搭建，主要講述配置文件。 2、配置文件。註意：每次要拋棄上一次集群都考檢查配置文件，因為sentinel是靠更改配置文件實現功能的。
監聽埠。
第一行最後的那個2，是說明需要兩個sentinel確認客觀下線，需要切換，才能操作。
如果有需要密碼驗證的，要在這裡添加密碼信息，否則不能通訊。
在配置文件後面幾行是啟動後系統自動添加。
3、啟動。
啟動之後，本實驗就是3台redis，三台sentinel，sentinel的配置文件自動填寫了sentinel集群和redis集群的信息。因為網路影響，所以單單憑一臺sentinel之言就隨便切換，所以一般情況需要3台sentinel以上。
確認5268是master，連接兩個slave。
4、測試。
a、關掉5268redis。
b、檢查4157和5257redis。發現master已經轉移到5257。
c、查看轉移日誌。
+failover-state-reconf-slaves master mymaster
…………
+failover-end master mymaster
第一行是確認預先的架構覆核標準。
第二行認為5268已經客觀下線。
第三行表示準備重寫主從架構的配置文件。
第四行表示開始重寫。
第五行表示故障切換處理5268完畢.。
第六、七行記錄在sentinel中已經認為4157和5268作為slave已經追隨5257master。
第九行sentinel認為5268已經淪落為slave，但是並不線上。緊接著標記主觀下線。
第十行表示5268重啟後符合slave標準，用“-”移除主觀下線記錄。
但是，查了兩次5257，並沒有發現5268的信息。於是我們查看redis5258的日誌，看沒有連上master是怎麼回事，反正sentinel那邊已經認為連上。
d、恢復後的redis5268的日誌。（異常處理）
NOAUTH Authentication required.
滿滿的認證不成功，已經很明顯告知，5268恢復之後就是slave了，因為此時的5257已經有了密碼，而5268沒有密碼記錄，自然沒有認證成功連上master5257。
所以在redis5268加上在master面前的認證密碼。
masterauth hodge01
e、重啟驗證。
重啟redis5268
檢查redis master5257，發現5268已經連上。
到此為止，sentinel支持的redis高可用集群就全部完成，IP自動切換方面下次探索。
