Redis Sentinel 機制與用法（二）
轉載：https://segmentfault.com/a/1190000002685515
概述
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候選人列表，並根據以下順序來進行排序：
-
sentinel首先會根據slaves的優先順序來進行排序，優先順序越小排名越靠前（？）。
-
如果優先順序相同，則檢視複製的下標，哪個從master接收的複製資料多，哪個就靠前。
-
如果優先順序和下標都相同，就選擇程序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支援的合法命令如下：
-
PINGsentinel回覆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，應該遵循如下步驟：
-
停止所要刪除的sentinel
-
傳送一個
SENTINEL RESET *命令給所有其它的sentinel例項，如果你想要重置指定master上面的sentinel，只需要把*號改為特定的名字，注意，需要一個接一個發，每次傳送的間隔不低於30秒。 -
檢查一下所有的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是隻讀的話，就能成功執行。