Redis哨兵配置及部署

文章目錄

• • • 哨兵
    • • 哨兵介紹
      • 哨兵的應用配置
      • 哨兵的實作原理
      • 哨兵部署

哨兵

哨兵介紹

作用:

監控Redis系統的運作情況

功能:

• 監控主資料庫和從資料庫是否正常運作
• 主資料庫出現故障時自動将從資料庫轉換為主資料庫

一個典型的哨兵架構

虛線表示主從複制,實線表示哨兵的監控路徑

多個哨兵監控

哨兵不僅會監控主資料庫和從資料庫,哨兵之間也會互相監控

哨兵的應用配置

1. 建立一個配置檔案,如sentinel.conf,内部為

   sentinel monitor mymaster 127.0.0.1 6379 1

   • mymaster表示要監控的主資料庫的名字,可以自己定義,隻能由大小寫字母 數字 ".-_"這三個字元組成
   • 127.0.0.1 6379 表示主資料庫的位址和端口号
   • 1 表示最低通過票數
   • 配置哨兵監控一個系統的時候,隻需要交控主資料庫即可,哨兵會自動發現所有複制該主資料庫的從資料庫
2. 啟動Sentinel程序,并将上述配置檔案的路徑傳遞給哨兵

   redis-sentinel /path/to/sentinel.conf

3. 傳回值
   • +slave 表示發現了從資料庫
   • +sdown表示哨兵主觀認為主資料庫停止服務了
   • +odown表示哨兵客觀認為主資料庫停止服務了
   • +try-failover表示哨兵開始進行故障恢複
   • +failover-end表示哨兵完成故障恢複
   • +switch-master表示主資料庫從…端口遷移到…端口
   • -sdown表示執行個體已經恢複
   • +convert-to-slave表示将…端口執行個體設定為現在主資料庫的從資料庫

哨兵的實作原理

• 一個哨兵節點可以同時監控多個redis主從環境
• 多個哨兵節點可以同時監控同一個Redis主從環境,形成網狀結構

1. 哨兵啟動後,會與要監控的主資料庫建立兩條連接配接,其中一條連接配接用來訂閱主資料的__sentinel__:hello頻道以擷取其他同樣監控該資料庫的哨兵節點的資訊

   另外哨兵也需要定期向主資料庫發送INFO指令來擷取主資料庫本身的資訊

2. 三個貫穿哨兵程序的生命周期的操作
   1. 每10s哨兵會向主資料庫和從資料庫發送INFO指令
      • 發送INFO指令使得哨兵可以獲得目前資料庫的相關資訊進而實作新節點的主動發現
   2. 每2s哨兵會向主資料庫和從資料庫的__sentinel__:hello頻道發送自己的資訊
   3. 每1s哨兵會向主資料庫 從資料庫和其他哨兵節點發送ping指令
      • 配置發送ping指令的時間通過

        down-after-milliseconds

      • sentinel down-after-milliseconds mymaster 60000 // 每隔1s發送一次ping指令
      • 當參數值小于1s時,哨兵會每隔設定的值的時間發送ping指令,當參數的值大于1s是,哨兵會每隔1s發送一次ping指令

主觀下線:

當超過down-after-milliseconds選項指定的時間後,如果ping的資料庫或節點仍然未進行回複,則哨兵認為主觀下線

客觀下線:

主觀下線表示從目前的哨兵程序來看,該節點已經下線,如果該節點是主資料庫,則哨兵會進一步判斷是否需要對其進行故障恢複:

哨兵發送

sentinel is-master-down-by-addr

指令詢問其他哨兵節點以了解他們是否也認為該資料庫主觀下線,如果達到

指定數量

時,

哨兵會認為其客觀下線,并選舉領頭的哨兵節點對主從系統發起故障恢複

指定數量指的是: sentinel monitor mymaster 127.0.0.1 6379 1 中的1

領頭哨兵選舉(Raft算法)

• 發現主資料庫客觀下線的哨兵節點(下面稱作A)向每個哨兵節點發送指令,要求對方選自己成為領頭哨兵
• 如果目标哨兵節點沒有選過其他人,則會同意A設定成零頭哨兵
• 如果A發現有超過半數且超過quorum參數值的哨兵節點同意選自己成為領頭哨兵,則A成功成為領頭哨兵
• 當有多個哨兵節點同時參選領頭哨兵,則會出現沒有任何節點當選的可能.此時每個參選節點将等待一個随機時間重新發起參選請求,進行下一輪選舉,直到選舉成功

  領頭哨兵挑選資料庫的依據

• 在所有線上的從資料庫中,選擇優先級最高的從資料庫,優先級可以通過slave-priority選項來設定
• 如果有多個最高優先級的資料庫,則複制的指令偏移量越大(即複制越完整)越優先
• 如果以上條件都一樣,則選擇運作ID較小的資料庫

哨兵部署

• 一個主系統中哨兵數量少,可靠性就會降低,當隻有一個哨兵,容易發生單點故障
• 相對穩妥的是使哨兵的視角盡可能與每一個節點的視角一緻
  • 為每個節點(無論是主資料庫還是從資料庫)部署一個哨兵
  • 使每個哨兵與其對應的節點的網絡環境相同或相近
• 設定quorum的值為N/2 + 1(其中N為哨兵節點數量),這樣使得隻有當大部分哨兵點同意後才會進行故障恢複
• 具體配置還要根據實際情況,因為當節點較多時,會産生大量備援連接配接,同時如果redis節點負載較高,會在一定程度上影響其對哨兵的回複以及與其同機的哨兵與其他節點的通信