Sentinel-Redis高可用方案(二):主從切換

原文地址爲:Sentinel-Redis高可用方案(二):主從切換

Redis 2.8版開始正式提供名爲Sentinel的主從切換方案,Sentinel用於管理多個Redis服務器實例,主要負責三個方面的任務:

    1. 監控(Monitoring): Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
    2. 提醒(Notification): 當被監控的某個 Redis 服務器出現問題時, Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
    3. 自動故障遷移(Automatic failover): 當一個主服務器不能正常工作時, Sentinel 會開始一次自動故障遷移操作, 它會將失效主服務器的其中一個從服務器升級爲新的主服務器, 並讓失效主服務器的其他從服務器改爲複製新的主服務器; 當客戶端試圖連接失效的主服務器時, 集羣也會向客戶端返回新主服務器的地址, 使得集羣可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分佈式系統, 你可以在一個架構中運行多個 Sentinel 進程(progress), 這些進程使用流言協議(gossip protocols)來接收關於主服務器是否下線的信息, 並使用投票協議(agreement protocols)來決定是否執行自動故障遷移, 以及選擇哪個從服務器作爲新的主服務器。

啓動Sentinel

使用--sentinel參數啓動,並必須指定一個對應的配置文件,系統會使用配置文件來保存 Sentinel 的當前狀態, 並在 Sentinel 重啓時通過載入配置文件來進行狀態還原。

    redis-server /path/to/sentinel.conf --sentinel

使用TCP端口26379,可以使用redis-cli或其他任何客戶端與其通訊。

如果啓動 Sentinel 時沒有指定相應的配置文件, 或者指定的配置文件不可寫(not writable), 那麼 Sentinel 會拒絕啓動。

配置Sentinel

以下是一段配置文件的示例:

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

    第一行配置指示 Sentinel 去監視一個名爲 mymaster 的主服務器, 這個主服務器的 IP 地址爲 127.0.0.1 , 端口號爲 6379 , 而將這個主服務器判斷爲失效至少需要 2 個 Sentinel 同意 (只要同意 Sentinel 的數量不達標,自動故障遷移就不會執行)。
    不過需要注意的是,無論你設置要多少個 Sentinel 同意才能判斷一個服務器失效,一個 Sentinel 都需要獲得系統中多數(majority) Sentinel 的支持,才能發起一次自動故障遷移,並預留一個給定的配置紀元 (Configuration Epoch ,一個配置紀元就是一個新主服務器配置的版本號)。也就是說,如果只有少數(minority)Sentinel 進程正常運作的情況下,是不能執行自動故障遷移的。

    down-after-milliseconds 選項指定了 Sentinel 認爲服務器已經斷線所需的毫秒數(判定爲主觀下線SDOWN)。
    parallel-syncs 選項指定了在執行故障轉移時, 最多可以有多少個從服務器同時對新的主服務器進行同步, 這個數字越小, 完成故障轉移所需的時間就越長,但越大就意味着越多的從服務器因爲複製而不可用。可以通過將這個值設爲 1 來保證每次只有一個從服務器處於不能處理命令請求的狀態。

主觀下線和客觀下線

    1. 主觀下線(Subjectively Down, 簡稱 SDOWN)指的是單個 Sentinel 實例對服務器做出的下線判斷。
    2. 客觀下線(Objectively Down, 簡稱 ODOWN)指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷, 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後, 得出的服務器下線判斷。

客觀下線條件只適用於主服務器: 對於任何其他類型的 Redis 實例, Sentinel 在將它們判斷爲下線前不需要進行協商, 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。
只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態, 這個 Sentinel 就可能會被其他 Sentinel 推選出, 並對失效的主服務器執行自動故障遷移操作。

每個Sentinel實例都執行的定時任務

    1. 每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發送一個 PING 命令。
    2. 如果一個實例(instance)距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值, 那麼這個實例會被 Sentinel 標記爲主觀下線。 一個有效回覆可以是: +PONG 、 -LOADING 或者 -MASTERDOWN 。
    3. 如果一個主服務器被標記爲主觀下線, 那麼正在監視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。
    4. 如果一個主服務器被標記爲主觀下線, 並且有足夠數量的 Sentinel (至少要達到配置文件指定的數量)在指定的時間範圍內同意這一判斷, 那麼這個主服務器被標記爲客觀下線。
    5. 在一般情況下, 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記爲客觀下線時, Sentinel 向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改爲每秒一次。
    6. 當沒有足夠數量的 Sentinel 同意主服務器已經下線, 主服務器的客觀下線狀態就會被移除。 當主服務器重新向 Sentinel 的 PING 命令返回有效回覆時, 主服務器的主管下線狀態就會被移除。

Sentinel API

有兩種方式可以與Sentinel進行通訊:指令、發佈與訂閱。

    Sentinel命令

       PING :返回 PONG 。
       SENTINEL masters :列出所有被監視的主服務器,以及這些主服務器的當前狀態;
       SENTINEL slaves <master name> :列出給定主服務器的所有從服務器,以及這些從服務器的當前狀態;
       SENTINEL get-master-addr-by-name <master name> : 返回給定名字的主服務器的 IP 地址和端口號。 如果這個主服務器正在執行故障轉移操作, 或者針對這個主服務器的故障轉移操作已經完成, 那麼這個                     命令返回新的主服務器的 IP 地址和端口號;
       SENTINEL reset <pattern> : 重置所有名字和給定模式 pattern 相匹配的主服務器。 pattern 參數是一個 Glob 風格的模式。 重置操作清楚主服務器目前的所有狀態, 包括正在執行中的故障轉移, 並移除目前已經發現和關聯的, 主服務器的所有從服務器和 Sentinel ;
       SENTINEL failover <master name> : 當主服務器失效時, 在不詢問其他 Sentinel 意見的情況下, 強制開始一次自動故障遷移。

客戶端可以通過SENTINEL get-master-addr-by-name <master name>獲取當前的主服務器IP地址和端口號,以及SENTINEL slaves <master name>獲取所有的Slaves信息

    發佈與訂閱信息

    客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 服務器: 你不可以使用 PUBLISH 命令向這個服務器發送信息, 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令, 通過訂閱給定的頻道來獲取相應的事件提醒。
   一個頻道能夠接收和這個頻道的名字相同的事件。 比如說, 名爲 +sdown 的頻道就可以接收所有實例進入主觀下線(SDOWN)狀態的事件。
   通過執行 PSUBSCRIBE * 命令可以接收所有事件信息。

        +switch-master <master name> <oldip> <oldport> <newip> <newport> :配置變更,主服務器的 IP 和地址已經改變。 這是絕大多數外部用戶都關心的信息。

    可以看出,我們使用Sentinel命令和發佈訂閱兩種機制就能很好的實現和客戶端的集成整合:
    使用get-master-addr-by-name和slaves指令可以獲取當前的Master和Slaves的地址和信息;而當發生故障轉移時,即Master發生切換,可以通過訂閱的+switch-master事件獲得最新的Master信息。

    *PS:更多Sentinel的可訂閱事件參見官方文檔

sentinel.conf中的notification-script

    在sentinel.conf中可以配置多個sentinel notification-script <master name> <shell script-path>, 如sentinel notification-script mymaster ./check.sh

    這個是在羣集failover時會觸發執行指定的腳本。腳本的執行結果若爲1,即稍後重試(最大重試次數爲10);若爲2,則執行結束。並且腳本最大執行時間爲60秒,超時會被終止執行。

    PS:目前會存在該腳本被執行多次的問題,查找資料有人解釋是:
        腳本分爲兩個級別, SENTINEL_LEADER 和 SENTINEL_OBSERVER ,前者僅由領頭 Sentinel 執行(一個 Sentinel),而後者由監視同一個 master 的所有 Sentinel 執行(多個 Sentinel)。


轉載請註明本文地址:Sentinel-Redis高可用方案(二):主從切換
發佈了0 篇原創文章 · 獲贊 104 · 訪問量 78萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章