redis哨兵

sentinel工作原理：

在主從節點和sentinel節點集合配置好之後，sentinel節點之間會互相發送消息，以檢測其餘sentinel節點是否正常工作，并且sentinel節點也會向主從節點發送消息，以檢測監控的主從節點是否正常工作。這裡如果主節點因為故障下線，那麼某個sentinel節點發送檢測消息給主節點時，如果在指定時間内收不到回複，那麼該sentinel就會主觀的判斷該主節點已經下線，那麼其會發送消息給其餘的sentinel節點，詢問其是否"認為"該主節點已下線，其餘的sentinel收到消息後也會發送檢測消息給主節點，如果其認為該主節點已經下線，那麼其會回複向其詢問的sentinel節點，告知其也認為主節點已經下線，當該sentinel節點最先收到超過指定數目（配置檔案中配置的數目和目前sentinel節點集合數的一半，這裡兩個數目的較大值）的sentinel節點回複說目前主節點已下線，那麼其就會對主節點進行故障轉移工作，故障轉移的基本思路是在從節點中選取某個從節點向其發送slaveof no one（假設選取的從節點為127.0.0.1:6380），使其稱為獨立的節點（也就是新的主節點），然後sentinel向其餘的從節點發送slaveof 127.0.0.1 6380指令使它們重新成為新的主節點的從節點。重新配置設定之後sentinel節點集合還會繼續監控已經下線的主節點（假設為127.0.0.1:6379），如果其重新上線，那麼sentinel會向其發送slaveof指令，使其成為新的主機點的從節點，如此故障轉移工作完成。

環境：centos6.5 + redis 3.2.10

master：10.20.44.13:6379

slave1：10.20.44.17:6379

slave2：10.20.44.18:6379

redis主從安裝：

略

sentinel安裝：

[root@master ~]# cp /usr/local/redis/sentinel.conf /etc/
[root@master ~]# cat /etc/sentinel.conf                         ####注意，以下配置是有順序的，不能打亂順序
daemonize yes  
port 26379                                 #####哨兵自己的端口
dir /usr/local/redis/logs
sentinel monitor mymaster 10.20.44.13 6379 2                #配置主節點的ip和端口，2表示在sentinel叢集中隻要有兩個節點檢測到redis主節點出故障就進行切換，單sentinel節點無效(自己測試發現的)
sentinel down-after-milliseconds mymaster 30000                #如果30s内mymaster無響應，則認為mymaster當機了  
sentinel failover-timeout mymaster 10000                        #如果10秒後,mysater仍沒活過來，則啟動failover  
sentinel auth-pass mymaster 123456                                #redis主節點密碼 ，如果master沒設定密碼則不需要這一行
sentinel parallel-syncs mymaster 1                                #在發生failover主備切換時，這個選項指定了最多可以有多少個slave同時對新的master進行同步，同步時不能處理請求
logfile "sentinel.log"
protected-mode no                                        注意：在redis3.2之後一定要在哨兵配置檔案中加入這一項，不然會哨兵節點之間無法通信，日志中會出現其餘節點sdown情況           

報錯：

排查方法：

[root@master etc]# redis-cli -p 26379 -h 10.20.44.13 info              #出現下面錯誤即表示哨兵節點間無法通信，要去掉保護模式。
![image](https://yqfile.alicdn.com/e29f8372ca284ffc48e7d664a0e0c097d0fa9399.png)
           

驗證sentinel：

[root@master etc]# redis-sentinel /etc/sentinel.conf
[root@master etc]# netstat -tnlp |grep 26379
[root@master etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1
127.0.0.1:26379> sentinel masters                        //确認master的資訊
127.0.0.1:26379> sentinel slaves mymaster                //确認slave資訊


配置slave2,slave3服務：
[root@slave1 ]# scp /etc/sentinel.conf  10.20.44.17:/etc/sentinel.conf
[root@slave1 ]# scp /etc/sentinel.conf  10.20.44.18:/etc/sentinel.conf

啟動slave2，slave3的哨兵服務:
[root@slave2 ]# redis-sentinel /etc/sentilen.conf
[root@slave3 ]# redis-sentinel /etc/sentilen.conf


驗證自動切換：
[root@master etc]# redis-cli -p 6379 shutdown                //将主庫關機
[root@slave1 ]# redis-cli -p 6379                //登入slave1，檢視輸出結果中角色是否為master
127.0.0.1:6380> info replication                           

在這個系統中，初始狀态下redis3是master, redis1和redis2是slave。之後redis3所在的主機網絡不可用了，sentinel1和sentinel2啟動了failover并把redis1選舉為master，并且更新了自己的sentinel配置。
但是sentinel3依然持着的是舊配置，因為它與外界隔離了。如果此時用戶端所連接配接的master被網絡隔離，會發生什麼呢？
用戶端将依然可以向redis3寫資料，但是當網絡恢複後，redis3就會變成redis的一個slave，那麼在網絡隔離期間，用戶端向redis3寫的資料将會丢失。

你可以通過以下配置來配置redis3和redis1，使得資料不會丢失。修改redis.conf配置檔案：
min-slaves-to-write 1
min-slaves-max-lag 10
通過上面的配置，當一個redis是master時，如果它不能向至少一個slave寫資料(上面的min-slaves-to-write指定了slave的數量)，它将會拒絕接受用戶端的寫請求。
由于複制是異步的，master無法向slave寫資料意味着slave要麼斷開連接配接了，要麼不在指定時間内向master發送同步資料的請求了(上面的min-slaves-max-lag指定了這個時間)。           

Sentinel指令
127.0.0.1:26379> sentinel masters
127.0.0.1:26379> sentinel slaves mymaster
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
127.0.0.1:26379> SENTINEL reset mymaster
127.0.0.1:26379> SENTINEL failover mymaster
127.0.0.1:26379> SENTINEL flushconfig mymaster