Redis Sentinel 架構原理詳解(三)

前言

前面Redis Sentinel 架構原理詳解(二)介紹了redis集羣中sentinel的三種定時監控任務,還了解了主觀下線,客觀下線的概念,以及sentinel is-master-down-by-addr命令的作用。這裏再和大家一起學習下Redis Sentinel架構故障轉移前的Sentinel leader 節點選舉,以及新的redis master節點如何選擇。

故障轉移前的leader選舉

當sentinel集羣確認master odown,需要選舉出一個leader節點來進行故障轉移,選舉過程如下:

  1. 每個在線的sentinel節點都有資格成爲leader,當它確認主節點客觀下線時候,會向其他 sentinel 節點發送sentinel is-master-down-by-addr命令,要求將自己設置爲leader,比如sentinel-0節點首先發起請求成爲leader的請求。

  2. 每個sentinel節點都只能投出一票,於是當 sentinel-0 節點發起成爲 leader 的請求後,會得到sentinel-1和sentinel-2節點的投票,總共得到2票,得到的票數和以下公式計算的值作比較:

  max(quorum, num(sentinels) / 2 + 1)
= max(2, 3 / 2 + 1) 
= max(2, 1 + 1) 
= max(2, 2)
= 2

當得到的票數 >= max(quorum, num(sentinels) / 2 + 1) 的值,那麼該sentinel節點成爲leader,於是,sentinel-0節點成爲 leader。

      3.比如下一個確認master客觀下線的sentinel 節點爲sentinel-1,當它發起成爲leader的請求後,由於sentinel-2節點已經給 sentinel-0節點投過票了,於是它只能得到 sentinel-0節點投的一票,所以它不能成爲leader,而當 sentinel-2 發起請求成爲 leader 的請求後,它一票都得不到。於是當已經選舉出leader後,就不會再繼續進行選舉流程了,因爲是沒有意義的。

      4.如果一次選舉沒有選舉出leader,那麼會進行下一次選舉。

      5.正常情況下,哪個 sentinel節點最先確認master客觀下線,哪個sentinel節點就會成爲執行故障轉移的 leader。

故障轉移前新的master選擇

要執行故障轉移,首先要從 slave中選擇一個作爲新的 master,選擇的準則如下:

不選擇不健康的 slave,以下狀態的slave是不健康的:

  • 主觀下線的 slave
  • 大於等於5秒沒有回覆過sentinel節點ping響應的slave
  • 與master失聯超過down-after-milliseconds * 10秒的slave

對健康的slave進行排序

  • 選擇 priority(從節點優先級,可配置,默認100)最低的從節點,如果有優先級相同的節點,進行下一步。注意如果這個值配置爲0,則代表禁止該節點成爲 master。
  • 選擇複製偏移量最大的從節點(複製的最完整),如果有複製偏移量相等的節點,進行下一步。
  • 選擇 runid 最小的從節點。

然後就是leader進行故障轉移的過程了:

  • leader 對選擇出來的要成爲 new master 的 slave 執行 slaveof no one 命令讓其成爲 new master。
  • leader 會向剩餘的slave發送命令,讓它們成爲new master的slave。
  • leader 會將old master更新爲slave點,並保持着對其關注,當其恢復後命令它去複製new master。複製規則和parallel-syncs配置有關。該配置指定了在執行故障轉移時,最多可以有多少個 slave 同時對 new master 進行同步,這個數字越小,完成故障轉移所需的時間就越長。如果從服務器被設置爲允許使用過期數據集(redis.conf 中slave-serve-stale-data配置) ,那麼你可能不希望所有 slave 都在同一時間向 new master 發送同步請求,因爲儘管複製過程的絕大部分步驟都不會阻塞slave, 但 slave 在 load new master 發來的 RDB 文件時, 仍然會造成其在一段時間內不能處理請求。如果全部 slave 一起對 new master 進行同步, 那麼就可能會造成所有 slave 在短時間內全部不可用的情況出現。你可以通過將這個值設爲1來保證故障轉移後最多隻有一個 slave 處於不可用狀態。但這樣的話,全部 slave 的數據同步就是串行的,這樣就會增加故障轉移整個過程的時間。

總結

這裏介紹了redis哨兵集羣中sentinel的leader如何選舉,以及redis主從中的新master如何選擇,後續再一起學習下Sentinel集羣的quorum 和majority,configuration epoch,以及Redis Sentinel可能出現的問題以及解決辦法。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章