5、redis監控工具--redis sentinel使用說明及注意事項

標籤：sentinel redis監控

        通過前面4篇筆記，大家對redis的基本概念及配置已經有瞭解，本篇筆記重點說明如何通過官方發布的redis sentinel工具來監控redis的運行狀態。另外，對sentinel使用過程中的注意事項做些討論。

1. Redis Sentinel功能
        Redis Sentinel是一套用於管理Redis執行個體的分布式系統，主要完成3項任務：
         1) Monitoring：持續監控Redis master或slave執行個體的運行情況是否符合預期
         2) Notification：若被監控的Redis執行個體運行異常，sentinel會通過API通知外界（人或程式）
         3) Automation failover：若master執行個體故障，sentinel會重新選主並啟動自動故障切換：選擇slave-priority最小的那個slave執行個體並將其提升為master，同時修改其它slave的配置，使其master配置項指向新的master，當old master恢複重啟後，會自動降級為new master的slave。最後，根據配置，Redis Sentinel還會將新的master地址通知給當前正在訪問Redis的應用程式。

2. Redis Sentinel部署
        Sentinel作為一個分布式系統工具，建議多機房多機部署。

2.1 sentinel設定檔
        每個sentinel執行個體主要有6個配置項，按Redis叢集的實際部署情況進行配置即可，樣本如下： 

[plain] view plain copy 650) this.width=650;" src="https://code.csdn.net/assets/CODE_ico.png" alt="在CODE上查看代碼片" style="border:none;" height="12" width="12" />650) this.width=650;" src="https://code.csdn.net/assets/ico_fork.svg" alt="派生到My Code片" style="border:none;" height="12" width="12" />

1. port 26329  

2. sentinel monitor mymaster 127.0.0.1 6379 2  

3. sentinel down-after-milliseconds mymaster 60000  

4. sentinel failover-timeout mymaster 180000  

5. sentinel parallel-syncs mymaster  

6. sentinel notification-script <master-name> <script-path>  

        其中：
        port: 指定sentinel的偵聽連接埠（即與redis server或client建立tcp串連的連接埠）
        monitor: 指定sentinel要monitor的redis執行個體，包括一個redis執行個體的別名（alias）及redis執行個體的ip+port，該行最後的數字2表示至少2個setinel執行個體同時檢測到redis server異常時，才將redis server的狀態判決為real fail。也即，若這裡配置為2，但實際部署中sentinel只部署了1套，則即使redis執行個體已經掛掉，sentinel也不會給出任何警告。這一點需要特別引起注意。
        down-after-milliseconds: 指定sentinel監控到redis執行個體持續異常多長時間後，會判決其狀態為down。若實際業務需要sentinel儘快判決出redis執行個體異常，則該值可適當配小。
        failover-timeout: 若sentinel在該配置值內未能完成failover操作（即故障時master/slave自動切換），則認為本次failover失敗。該配置有4個用途，具體可參考sentinel.conf中的說明，限於篇幅，此處不再贅述。
        parallel-syncs: 指定failover過程中，同時被sentinel reconfigure的最大slave執行個體數。由於reconfigure過程中，對應的slave會中斷響應用戶端請求，故為避免所有的slave同時不可用，該值需適當配小。
        notification-script: 指定sentinel檢測到master-name指向的執行個體異常時，調用的警示指令碼。該配置項可選，但線上系統建議配置。

2.2 啟動監控系統
        設定檔修改完成後，啟動各監控進程即可，例如：

[plain] view plain copy 650) this.width=650;" src="https://code.csdn.net/assets/CODE_ico.png" alt="在CODE上查看代碼片" style="border:none;" height="12" width="12" />650) this.width=650;" src="https://code.csdn.net/assets/ico_fork.svg" alt="派生到My Code片" style="border:none;" height="12" width="12" />

1. nohup ./bin/redis-sentinel ./conf/sentinel.conf > ./log/redis-sentinel.log 2>&1 &  

2.3 sentinel使用情境實測
        為調研並掌握sentinel用法，我搭建了redis測試環境並做了一系列實驗，下面對實驗情況做詳細說明。
        特別說明：由於下面的內容可能會涉及到公司內網地址，故為避免不必要的麻煩，文字或出現ip地址的地方做了塗抹，但不影響說明問題。
        實驗環境（one master / two slaves / two sentinels）：
           a. 一個master（slave-priority為100）部署在ip為xx.xx.234.67的機器上；
           b. 兩個slaves（slave-priority分別為90/100）的均部署在ip為xx.xx.234.49的機器上；
           c. 啟用兩個sentinel進程監控redis叢集狀態
        做了6種case的測試，結果說明如下：
        Case1: 依次啟動master進程及2個slave進程後，再啟動2個sentinel進程，sentinel可以正常識別出主從關係
        Case2: 用shutdown命令停掉master，則sentinel自動選slave-priority小的那個slave進程為new master，同時，自動將另一個slave進程的master指向該new master
        Case3: 在case2基礎上，重啟old master，sentinel會將其降級為slave，其master指向case2選出的新主
        Case4: 將master和2個slave執行個體的slave-priority配為互不相同的值，在Case1基礎上，shutdown當前的master，在sentinel已選出新主且reconfigure其它執行個體使它們指向新主後（從old master異常到觸發sentinel重新選主的時間由使用者通過sentinel.conf的down-after-milliseconds配置項指定），重啟old master，系統最終狀態與Case3一致，即old master已降級為slave，其master指向sentinel選出的新主。若在sentinel已選出新主但尚未完成其它執行個體的reconfigure之前，重啟old master，則整個系統會出現無法選出new master的異常，詳情見下面Case5的描述。
        Case5: 將master和2個slave執行個體的slave-priority均配為相同的值，在Case1基礎上，shutdown當前的master，在sentinel已選出新主且reconfigure其它執行個體使它們指向新主後，重啟old master，系統最終狀態與Case3一致，即old master已降級為slave，其master指向sentinel選出的新主。在所有slave-priority配置為相同值的情況下，sentinel會將各slave執行個體中runid最小的slave提升為master（前提是該slave對應的redis.conf中允許其被promote為master）。與Case4出現的異常情況類似，若在sentinel選出新主但尚未完成其它執行個體的reconfigure之前，重啟old master，會發現sentinel的自動故障切換機制已然淩亂了。
        詳細的異常情況如下所述。     
        old master部署在ip為xx.xx.234.67的機器上且port預設為6379，sentinel切換異常後，對該old master執行info命令輸出如下：
             650) this.width=650;" src="http://img.blog.csdn.net/20131230170014875?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc2x2aGVy/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" style="border:none;" />
        slave-00執行個體在ip為xx.xx.234.49的機器上且port配為6378，sentinel切換異常後，info輸出如下：
             650) this.width=650;" src="http://img.blog.csdn.net/20131230170129234?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc2x2aGVy/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" style="border:none;" /> 
        slave-01執行個體在ip為xx.xx.234.49的機器上（與slave-00同機部署）且port配為6377，info輸出如下：
             650) this.width=650;" src="http://img.blog.csdn.net/20131230170200375?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc2x2aGVy/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" style="border:none;" /> 
        從上面3個redis執行個體的輸出情況看，3個均認為自己是slave，整個系統無主！其中，位於xx.xx.234.67的old master（注意上面第1圖的master_host欄位）和位於xx.xx.234.49的salve-00（注意上面第2圖的master_host欄位）均認為slave-01為new master，而位於xx.xx.234.49的slave-01則認為自己仍然為slave，認為old master目前還是master（注意上面第3圖的master_host欄位）。
        從sentinel進程日誌看，其無法選出新主，即sentinel無法確認兩個master candidates到底哪個是new master，在兩個執行個體間頻繁切換：
650) this.width=650;" src="http://img.blog.csdn.net/20131230172424312?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc2x2aGVy/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" style="border:none;" />
        這種情況務在實際營運時務必要引起注意！
        Case 6: 在系統已進入Case5所示的異常狀態後，shutdown兩個master candidates中的一個執行個體，sentinel仍然無法正常選主，直至3個執行個體全部shutdown，整個系統仍然無主。基本可以確定監控系統內部邏輯狀態已經混亂了。

2.4 結論
        若master執行個體故障，則最好等sentinel選出new master且穩定後（選新主並完成切換的時間與配置有關，典型值在1分鐘之內），再重啟old master，避免引發sentinel的誤判，導致整個系統無法選出new master。

本文出自 “linux營運菜鳥” 部落格，請務必保留此出處http://zhangchuang.blog.51cto.com/10884116/1786973

5、redis監控工具--redis sentinel使用說明及注意事項