Redis Sentinel 機制與用法（二）

本專欄與Redis相關的文章

Redis Sentinel機制與用法（一）
Redis Sentinel機制與用法（二）
Jedis的JedisSentinelPool源代碼分析
Jedis的Sharded源代碼分析
Redis 主從 Replication 的配置
詳解Redis SORT命令
JedisCommand接口說明

本文參考翻譯自 《Redis Sentinel Documentation》

續前篇《Redis Sentinel機制與用法（一）》

概述

Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis作Master-slave的高可用方案時，假如master宕機了，Redis自己(包括它的不少客戶端)都沒有實現自動進行主備切換，而Redis-sentinel自己也是一個獨立運行的進程，它能監控多個master-slave集羣，發現master宕機後能進行自懂切換。

它的主要功能有如下幾點

• 不時地監控redis是否按照預期良好地運行;
• 若是發現某個redis節點運行出現情況，可以通知另一個進程(例如它的客戶端);
• 可以進行自動切換。當一個master節點不可用時，可以選舉出master的多個slave(若是有超過一個slave的話)中的一個來做爲新的master,其它的slave節點會將它所追隨的master的地址改成被提高爲master的slave的新地址。

<br/>

無failover時的配置糾正

即便當前沒有failover正在進行，sentinel依然會使用當前配置去設置監控的master。特別是：

• 根據最新配置確認爲slaves的節點卻聲稱本身是master(參考上文例子中被網絡隔離後的的redis3)，這時它們會被從新配置爲當前master的slave。
• 若是slaves鏈接了一個錯誤的master，將會被改正過來，鏈接到正確的master。

Slave選舉與優先級

當一個sentinel準備好了要進行failover，而且收到了其餘sentinel的受權，那麼就須要選舉出一個合適的slave來作爲新的master。

slave的選舉主要會評估slave的如下幾個方面：

• 與master斷開鏈接的次數
• Slave的優先級
• 數據複製的下標(用來評估slave當前擁有多少master的數據)
• 進程ID

若是一個slave與master失去聯繫超過10次，而且每次都超過了配置的最大失聯時間(down-after-milliseconds option)，而且，若是sentinel在進行failover時發現slave失聯，那麼這個slave就會被sentinel認爲不適合用來作新master的。

更嚴格的定義是，若是一個slave持續斷開鏈接的時間超過

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

就會被認爲失去選舉資格。
符合上述條件的slave纔會被列入master候選人列表，並根據如下順序來進行排序：

1. sentinel首先會根據slaves的優先級來進行排序，優先級越小排名越靠前（？）。
2. 若是優先級相同，則查看複製的下標，哪一個從master接收的複製數據多，哪一個就靠前。
3. 若是優先級和下標都相同，就選擇進程ID較小的那個。

一個redis不管是master仍是slave，都必須在配置中指定一個slave優先級。要注意到master也是有可能經過failover變成slave的。

若是一個redis的slave優先級配置爲0，那麼它將永遠不會被選爲master。可是它依然會從master哪裏複製數據。

Sentinel和Redis身份驗證

當一個master配置爲須要密碼才能鏈接時，客戶端和slave在鏈接時都須要提供密碼。

master經過requirepass設置自身的密碼，不提供密碼沒法鏈接到這個master。
slave經過masterauth來設置訪問master時的密碼。

可是當使用了sentinel時，因爲一個master可能會變成一個slave，一個slave也可能會變成master，因此須要同時設置上述兩個配置項。

Sentinel API

Sentinel默認運行在26379端口上，sentinel支持redis協議，因此可使用redis-cli客戶端或者其餘可用的客戶端來與sentinel通訊。

有兩種方式可以與sentinel通訊：

• 一種是直接使用客戶端向它發消息
• 另一種是使用發佈/訂閱模式來訂閱sentinel事件，好比說failover，或者某個redis實例運行出錯，等等。

Sentinel命令

sentinel支持的合法命令以下：

• PING sentinel回覆PONG.
• SENTINEL masters 顯示被監控的全部master以及它們的狀態.
• SENTINEL master <master name> 顯示指定master的信息和狀態；
• SENTINEL slaves <master name> 顯示指定master的全部slave以及它們的狀態；
• SENTINEL get-master-addr-by-name <master name> 返回指定master的ip和端口，若是正在進行failover或者failover已經完成，將會顯示被提高爲master的slave的ip和端口。
• SENTINEL reset <pattern> 重置名字匹配該正則表達式的全部的master的狀態信息，清楚其以前的狀態信息，以及slaves信息。
• SENTINEL failover <master name> 強制sentinel執行failover，而且不須要獲得其餘sentinel的贊成。可是failover後會將最新的配置發送給其餘sentinel。

動態修改Sentinel配置

從redis2.8.4開始，sentinel提供了一組API用來添加，刪除，修改master的配置。

須要注意的是，若是你經過API修改了一個sentinel的配置，sentinel不會把修改的配置告訴其餘sentinel。你須要本身手動地對多個sentinel發送修改配置的命令。

如下是一些修改sentinel配置的命令：

• SENTINEL MONITOR <name> <ip> <port> <quorum> 這個命令告訴sentinel去監聽一個新的master
• SENTINEL REMOVE <name> 命令sentinel放棄對某個master的監聽
• SENTINEL SET <name> <option> <value> 這個命令很像Redis的CONFIG SET命令，用來改變指定master的配置。支持多個<option><value>。例如如下實例：
• SENTINEL SET objects-cache-master down-after-milliseconds 1000

只要是配置文件中存在的配置項，均可以用SENTINEL SET命令來設置。這個還能夠用來設置master的屬性，好比說quorum(票數)，而不須要先刪除master，再從新添加master。例如：

SENTINEL SET objects-cache-master quorum 5

增長或刪除Sentinel

因爲有sentinel自動發現機制，因此添加一個sentinel到你的集羣中很是容易，你所須要作的只是監控到某個Master上，而後新添加的sentinel就能得到其餘sentinel的信息以及masterd全部的slave。

若是你須要添加多個sentinel，建議你一個接着一個添加，這樣能夠預防網絡隔離帶來的問題。你能夠每一個30秒添加一個sentinel。最後你能夠用SENTINEL MASTER mastername來檢查一下是否全部的sentinel都已經監控到了master。

刪除一個sentinel顯得有點複雜：由於sentinel永遠不會刪除一個已經存在過的sentinel，即便它已經與組織失去聯繫好久了。
要想刪除一個sentinel，應該遵循以下步驟：

1. 中止所要刪除的sentinel
2. 發送一個SENTINEL RESET * 命令給全部其它的sentinel實例，若是你想要重置指定master上面的sentinel，只須要把*號改成特定的名字，注意，須要一個接一個發，每次發送的間隔不低於30秒。
3. 檢查一下全部的sentinels是否都有一致的當前sentinel數。使用SENTINEL MASTER mastername 來查詢。

刪除舊master或者不可達slave

sentinel永遠會記錄好一個Master的slaves，即便slave已經與組織失聯很久了。這是頗有用的，由於sentinel集羣必須有能力把一個恢復可用的slave進行從新配置。

而且，failover後，失效的master將會被標記爲新master的一個slave，這樣的話，當它變得可用時，就會重新master上覆制數據。

而後，有時候你想要永久地刪除掉一個slave(有可能它曾經是個master)，你只須要發送一個SENTINEL RESET master命令給全部的sentinels，它們將會更新列表裏可以正確地複製master數據的slave。

發佈/訂閱

客戶端能夠向一個sentinel發送訂閱某個頻道的事件的命令，當有特定的事件發生時，sentinel會通知全部訂閱的客戶端。須要注意的是客戶端只能訂閱，不能發佈。

訂閱頻道的名字與事件的名字一致。例如，頻道名爲sdown 將會發布全部與SDOWN相關的消息給訂閱者。

若是想要訂閱全部消息，只需簡單地使用PSUBSCRIBE *

如下是全部你能夠收到的消息的消息格式，若是你訂閱了全部消息的話。第一個單詞是頻道的名字，其它是數據的格式。

注意：如下的instance details的格式是：

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

若是這個redis實例是一個master，那麼@以後的消息就不會顯示。

+reset-master <instance details> -- 當master被重置時.
    +slave <instance details> -- 當檢測到一個slave並添加進slave列表時.
    +failover-state-reconf-slaves <instance details> -- Failover狀態變爲reconf-slaves狀態時
    +failover-detected <instance details> -- 當failover發生時
    +slave-reconf-sent <instance details> -- sentinel發送SLAVEOF命令把它從新配置時
    +slave-reconf-inprog <instance details> -- slave被從新配置爲另一個master的slave，但數據複製還未發生時。
    +slave-reconf-done <instance details> -- slave被從新配置爲另一個master的slave而且數據複製已經與master同步時。
    -dup-sentinel <instance details> -- 刪除指定master上的冗餘sentinel時 (當一個sentinel從新啓動時，可能會發生這個事件).
    +sentinel <instance details> -- 當master增長了一個sentinel時。
    +sdown <instance details> -- 進入SDOWN狀態時;
    -sdown <instance details> -- 離開SDOWN狀態時。
    +odown <instance details> -- 進入ODOWN狀態時。
    -odown <instance details> -- 離開ODOWN狀態時。
    +new-epoch <instance details> -- 當前配置版本被更新時。
    +try-failover <instance details> -- 達到failover條件，正等待其餘sentinel的選舉。
    +elected-leader <instance details> -- 被選舉爲去執行failover的時候。
    +failover-state-select-slave <instance details> -- 開始要選擇一個slave當選新master時。
    no-good-slave <instance details> -- 沒有合適的slave來擔當新master
    selected-slave <instance details> -- 找到了一個適合的slave來擔當新master
    failover-state-send-slaveof-noone <instance details> -- 當把選擇爲新master的slave的身份進行切換的時候。
    failover-end-for-timeout <instance details> -- failover因爲超時而失敗時。
    failover-end <instance details> -- failover成功完成時。
    switch-master <master name> <oldip> <oldport> <newip> <newport> -- 當master的地址發生變化時。一般這是客戶端最感興趣的消息了。
    +tilt -- 進入Tilt模式。
    -tilt -- 退出Tilt模式。

TILT 模式

redis sentinel很是依賴系統時間，例如它會使用系統時間來判斷一個PING回覆用了多久的時間。
然而，假如系統時間被修改了，或者是系統十分繁忙，或者是進程堵塞了，sentinel可能會出現運行不正常的狀況。
當系統的穩定性降低時，TILT模式是sentinel能夠進入的一種的保護模式。當進入TILT模式時，sentinel會繼續監控工做，可是它不會有任何其餘動做，它也不會去迴應is-master-down-by-addr這樣的命令了，由於它在TILT模式下，檢測失效節點的能力已經變得讓人不可信任了。
若是系統恢復正常，持續30秒鐘，sentinel就會退出TITL模式。

-BUSY狀態

注意：該功能還未實現。

當一個腳本的運行時間超過配置的運行時間時，sentinel會返回一個-BUSY 錯誤信號。若是這件事發生在觸發一個failover以前，sentinel將會發送一個SCRIPT KILL命令，若是script是隻讀的話，就能成功執行。