Redis哨兵的配置和原理

哨兵

在一個典型的一主多從的Redis系統中,當主數據庫遇到異常中斷服務後,須要手動選擇一個從數據庫升級爲主數據庫,整個過程須要人工介入,難以自動化。redis

Redis2.8提供了哨兵2.0(2.6提供了1.0,可是問題較多),哨兵顧名思義就是監控Redis系統的運行情況。它的功能包括一下兩個:算法

  • 監控主數據庫和從數據庫是否正常運行;
  • 主數據庫出現故障時自動將從數據庫升級爲主數據庫;

哨兵是一個獨立的進行,在一個一主多從的Redis系統中,可使用多個哨兵監控整個Redis系統,哨兵之間也會互相監控。數據庫

配置

基於前面的一主兩從架構,爲他們加入哨兵。bash

能夠在三個redis節點的redis目錄下找到sentinel.conf文件,這個文件就是哨兵的配置文件,修改配置以下:網絡

sentinel monitor mymaster 192.168.2.101 6379 3

其中mymaster是要監控的主數據庫名字,能夠自定義;架構

接下來是主數據庫的ip和端口;併發

最後一個3是指哨兵最低經過票數;測試

若是你須要後臺啓動,則修改daemonize參數:spa

daemonize yes

配置後若是有防火牆,不要忘記打開哨兵的端口,默認是26379。code

最後,開啓哨兵:

redis-sentinel /yourpath/sentinel.conf

作個測試,關閉主數據庫(192.168.2.101)後,等待30秒(默認30秒):

  • 哨兵將從數據庫中的一個節點升級成主數據庫(192.168.2.102);
  • 將另外一個從數據庫(192.168.2.103)的主數據庫(192.168.2.101)切換到新的主數據庫(192.168.2.102);

隨後啓動剛纔關閉的主數據庫(192.168.2.101)

  • 哨兵自動將其轉爲從數據庫;

原理

監控過程

哨兵啓動後,會與要監控的主數據庫創建兩條鏈接:

  1. 一條用來用來訂閱__sentinel__:hello頻道以獲取其餘哨兵節點的信息;
  2. 另外一條用來按期向主數據庫發送INFO等命令來獲取主數據庫自己的信息;

在和主數據庫創建鏈接後,哨兵會定時執行下面3個操做:

  1. 每10秒哨兵會向主數據庫和從數據庫發送INFO命令;
  2. 每2秒哨兵會向主數據庫和從數據庫的__sentinel__:hello頻道發送本身的信息;
  3. 每1秒哨兵會向主數據庫和從數據庫和其餘哨兵發送PING命令;

第一個操做是發送INFO命令,目的是獲取主數據庫的信息,以及主數據庫的從數據庫的信息,從而實現新節點的自動發現,並對從數據庫也創建兩條鏈接。

第二個操做是訂閱__sentinel__:hello頻道,併發送哨兵自己的信息,與一樣監控該數據庫的其餘哨兵分享本身的信息,同時也能識別哨兵是不是新哨兵。哨兵與哨兵之間也會創建一個連接,用來發送PING命令;

第三個操做是發送PING命令,在發現了從數據庫和其餘哨兵後,要作的就是定時監控Redis服務是否中止,時間間隔與配置文件中的down-after-milliseconds有關,當這個值小於1秒時,哨兵會每隔該值的時間發送PING命令,當這個值大於1秒時,哨兵會每隔1秒發送一次PING命令。

配置方式是在sentinel.conf文件中加入:

sentinel down-after-milliseconds mymaster 600 # 600毫秒發送一個PING

當超過down-after-milliseconds時,若是PING的數據庫未回覆,則哨兵認爲其主觀下線。主觀下線能夠理解爲當前的哨兵認爲該節點下線了。

若是該節點是主數據庫,則哨兵們會進一步判斷是否須要對其進行故障修復:

哨兵會發送SENTINEL is-master-down-by-addr命令詢問其餘哨兵,判斷他們是否也認爲該主數據庫下線,若是達到quorum參數,也就是咱們在配置哨兵時的命令:

sentinel monitor mymaster 192.168.2.101 6379 3

的最後一個參數3,哨兵們會認爲這個主數據庫客觀下線,並選舉一個領頭哨兵對主從系統發起故障恢復。

領頭哨兵選舉

要進行故障恢復,則須要選舉出一個領頭哨兵,領頭哨兵的選擇算法是Raft算法,具體過程以下:

發現主數據庫客觀下線的哨兵節點(A節點)想每一個哨兵節點發送命令,要求對方選擇本身成爲領頭哨兵;

若是目標哨兵節點沒有選擇過其餘人,則會贊成將A設置成領頭哨兵;

若是A發現超過半數且超過quorum參數個哨兵節點贊成選擇本身,則A成功成爲領頭哨兵;

當有多個哨兵同時參選,則會出現沒有任何節點當選的可能,此時每一個參選節點將等待一個隨即時間從新發起競選,直到選舉成功。

故障恢復

選擇出領頭哨兵後,會把從數據庫中的一個挑選出來升級爲主數據庫:

  1. 全部先線的從數據庫中,選擇優先級最高的,優先級能夠經過slave-priority來設置;
  2. 若是有多個同樣優先級的從數據庫,則複製的命令偏移量越大,越優先(與down掉的主數據庫最接近);
  3. 若是還有多個備選,則選擇運行ID較小的(運行ID不會重複);

選擇好節點後,領頭哨兵將想這個節點發送slaveof no one,升級他爲主數據庫。

而後想其餘從數據庫發送slaveof命令切換主數據庫。

最後更新內部的記錄,將已經中止服務的舊的主數據庫更新爲新的主數據庫的從數據庫,當其回覆後自動以從數據庫的身份加入到主從架構中。

哨兵部署

哨兵的推薦部署方案:

  1. 爲每一個節點(不管是主數據庫仍是從數據庫)都部署一個哨兵;
  2. 使每一個哨兵與其對應的節點的網絡環境相同或相近;

設置quorum的值爲N/2+1,這樣使得只有當大部分哨兵統一後纔會選擇領頭哨兵進行故障恢復;

相關文章
相關標籤/搜索