sentinel

• index
• next |
• previous |
• Redis 指令參考 

Sentinel

本文檔翻譯自： http://redis.io/topics/sentinel 。

Redis 的 Sentinel 系統用于管理多個 Redis 伺服器（instance）， 該系統執行以下三個任務：

• 監控（Monitoring）： Sentinel 會不斷地檢查你的主伺服器和從伺服器是否運作正常。
• 提醒（Notification）： 當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理者或者其他應用程式發送通知。
• 自動故障遷移（Automatic failover）： 當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會将失效主伺服器的其中一個從伺服器更新為新的主伺服器， 并讓失效主伺服器的其他從伺服器改為複制新的主伺服器； 當用戶端試圖連接配接失效的主伺服器時， 叢集也會向用戶端傳回新主伺服器的位址， 使得叢集可以使用新主伺服器代替失效伺服器。

Redis Sentinel 是一個分布式系統， 你可以在一個架構中運作多個 Sentinel 程序（progress）， 這些程序使用流言協定（gossip protocols)來接收關于主伺服器是否下線的資訊， 并使用投票協定（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從伺服器作為新的主伺服器。

雖然 Redis Sentinel 釋出為一個單獨的可執行檔案 redis-sentinel ， 但實際上它隻是一個運作在特殊模式下的 Redis 伺服器， 你可以在啟動一個普通 Redis 伺服器時通過給定 --sentinel 選項來啟動 Redis Sentinel 。

Redis Sentinel 目前仍在開發中， 這個文檔的内容可能随着 Sentinel 實作的修改而變更。

Redis Sentinel 相容 Redis 2.4.16 或以上版本， 推薦使用 Redis 2.8.0 或以上的版本。

擷取 Sentinel

目前 Sentinel 系統是 Redis 的 unstable 分支的一部分， 你必須到 Redis 項目的 Github 頁面 克隆一份 unstable 分值， 然後通過編譯來獲得 Sentinel 系統。

Sentinel 程式可以在編譯後的 src 文檔中發現， 它是一個命名為 redis-sentinel 的程式。

你也可以通過下一節介紹的方法， 讓 redis-server 程式運作在 Sentinel 模式之下。

另外， 一個新版本的 Sentinel 已經包含在了 Redis 2.8.0 版本的釋出檔案中。

啟動 Sentinel

對于 redis-sentinel 程式， 你可以用以下指令來啟動 Sentinel 系統：

redis-sentinel /path/to/sentinel.conf      

對于 redis-server 程式， 你可以用以下指令來啟動一個運作在 Sentinel 模式下的 Redis 伺服器：

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

兩種方法都可以啟動一個 Sentinel 執行個體。

啟動 Sentinel 執行個體必須指定相應的配置檔案， 系統會使用配置檔案來儲存 Sentinel 的目前狀态， 并在 Sentinel 重新開機時通過載入配置檔案來進行狀态還原。

如果啟動 Sentinel 時沒有指定相應的配置檔案， 或者指定的配置檔案不可寫（not writable）， 那麼 Sentinel 會拒絕啟動。

配置 Sentinel

Redis 源碼中包含了一個名為 sentinel.conf 的檔案， 這個檔案是一個帶有詳細注釋的 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 程序正常運作的情況下， Sentinel 是不能執行自動故障遷移的。

其他選項的基本格式如下：

sentinel <選項的名字> <主伺服器的名字> <選項的值>      

各個選項的功能如下：

• down-after-milliseconds 選項指定了 Sentinel 認為伺服器已經斷線所需的毫秒數。

  如果伺服器在給定的毫秒數之内， 沒有傳回 Sentinel 發送的 PING 指令的回複， 或者傳回一個錯誤， 那麼 Sentinel 将這個伺服器标記為主觀下線（subjectively down，簡稱 SDOWN ）。

  不過隻有一個 Sentinel 将伺服器标記為主觀下線并不一定會引起伺服器的自動故障遷移： 隻有在足夠數量的 Sentinel 都将一個伺服器标記為主觀下線之後， 伺服器才會被标記為客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移才會執行。

  将伺服器标記為客觀下線所需的 Sentinel 數量由對主伺服器的配置決定。

• parallel-syncs 選項指定了在執行故障轉移時， 最多可以有多少個從伺服器同時對新的主伺服器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長。

  如果從伺服器被設定為允許使用過期資料集（參見對 redis.conf 檔案中對 slave-serve-stale-data 選項的說明）， 那麼你可能不希望所有從伺服器都在同一時間向新的主伺服器發送同步請求， 因為盡管複制過程的絕大部分步驟都不會阻塞從伺服器， 但從伺服器在載入主伺服器發來的 RDB 檔案時， 仍然會造成從伺服器在一段時間内不能處理指令請求： 如果全部從伺服器一起對新的主伺服器進行同步， 那麼就可能會造成所有從伺服器在短時間内全部不可用的情況出現。

  你可以通過将這個值設為 1 來保證每次隻有一個從伺服器處于不能處理指令請求的狀态。

本文檔剩餘的内容将對 Sentinel 系統的其他選項進行介紹， 示例配置檔案 sentinel.conf 也對相關的選項進行了完整的注釋。

主觀下線和客觀下線

前面說過， Redis 的 Sentinel 中關于下線（down）有兩個不同的概念：

• 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 執行個體對伺服器做出的下線判斷。
• 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 執行個體在對同一個伺服器做出 SDOWN 判斷， 并且通過SENTINEL is-master-down-by-addr 指令互相交流之後， 得出的伺服器下線判斷。 （一個 Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr 指令來詢問對方是否認為給定的伺服器已下線。）

如果一個伺服器沒有在 master-down-after-milliseconds 選項所指定的時間内， 對向它發送 PING 指令的 Sentinel 傳回一個有效回複（valid reply）， 那麼 Sentinel 就會将這個伺服器标記為主觀下線。

伺服器對 PING 指令的有效回複可以是以下三種回複的其中一種：

• 傳回 +PONG 。
• 傳回 -LOADING 錯誤。
• 傳回 -MASTERDOWN 錯誤。

如果伺服器傳回除以上三種回複之外的其他回複， 又或者在指定時間内沒有回複 PING 指令， 那麼 Sentinel 認為伺服器傳回的回複無效（non-valid）。

注意， 一個伺服器必須在 master-down-after-milliseconds 毫秒内， 一直傳回無效回複才會被 Sentinel 标記為主觀下線。

舉個例子， 如果 master-down-after-milliseconds 選項的值為 30000 毫秒（30 秒）， 那麼隻要伺服器能在每 29 秒之内傳回至少一次有效回複， 這個伺服器就仍然會被認為是處于正常狀态的。

從主觀下線狀态切換到客觀下線狀态并沒有使用嚴格的法定人數算法（strong quorum algorithm）， 而是使用了流言協定： 如果 Sentinel 在給定的時間範圍内， 從其他 Sentinel 那裡接收到了足夠數量的主伺服器下線報告， 那麼 Sentinel 就會将主伺服器的狀态從主觀下線改變為客觀下線。 如果之後其他 Sentinel 不再報告主伺服器已下線， 那麼客觀下線狀态就會被移除。

客觀下線條件隻适用于主伺服器： 對于任何其他類型的 Redis 執行個體， Sentinel 在将它們判斷為下線前不需要進行協商， 是以從伺服器或者其他 Sentinel 永遠不會達到客觀下線條件。

隻要一個 Sentinel 發現某個主伺服器進入了客觀下線狀态， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 并對失效的主伺服器執行自動故障遷移操作。

每個 Sentinel 都需要定期執行的任務

• 每個 Sentinel 以每秒鐘一次的頻率向它所知的主伺服器、從伺服器以及其他 Sentinel 執行個體發送一個 PING 指令。
• 如果一個執行個體（instance）距離最後一次有效回複 PING 指令的時間超過 down-after-milliseconds 選項所指定的值， 那麼這個執行個體會被 Sentinel 标記為主觀下線。 一個有效回複可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
• 如果一個主伺服器被标記為主觀下線， 那麼正在監視這個主伺服器的所有 Sentinel 要以每秒一次的頻率确認主伺服器的确進入了主觀下線狀态。
• 如果一個主伺服器被标記為主觀下線， 并且有足夠數量的 Sentinel （至少要達到配置檔案指定的數量）在指定的時間範圍内同意這一判斷， 那麼這個主伺服器被标記為客觀下線。
• 在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主伺服器和從伺服器發送 INFO 指令。 當一個主伺服器被 Sentinel 标記為客觀下線時， Sentinel 向下線主伺服器的所有從伺服器發送 INFO 指令的頻率會從 10 秒一次改為每秒一次。
• 當沒有足夠數量的 Sentinel 同意主伺服器已經下線， 主伺服器的客觀下線狀态就會被移除。 當主伺服器重新向 Sentinel 的 PING指令傳回有效回複時， 主伺服器的主管下線狀态就會被移除。

自動發現 Sentinel 和從伺服器

一個 Sentinel 可以與其他多個 Sentinel 進行連接配接， 各個 Sentinel 之間可以互相檢查對方的可用性， 并進行資訊交換。

你無須為運作的每個 Sentinel 分别設定其他 Sentinel 的位址， 因為 Sentinel 可以通過釋出與訂閱功能來自動發現正在監視相同主伺服器的其他 Sentinel ， 這一功能是通過向頻道 __sentinel__:hello 發送資訊來實作的。

與此類似， 你也不必手動列出主伺服器屬下的所有從伺服器， 因為 Sentinel 可以通過詢問主伺服器來獲得所有從伺服器的資訊。

• 每個 Sentinel 會以每兩秒一次的頻率， 通過釋出與訂閱功能， 向被它監視的所有主伺服器和從伺服器的 __sentinel__:hello 頻道發送一條資訊， 資訊中包含了 Sentinel 的 IP 位址、端口号和運作 ID （runid）。
• 每個 Sentinel 都訂閱了被它監視的所有主伺服器和從伺服器的 __sentinel__:hello 頻道， 查找之前未出現過的 sentinel （looking for unknown sentinels）。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會将新的 Sentinel 添加到一個清單中， 這個清單儲存了 Sentinel 已知的， 監視同一個主伺服器的所有其他 Sentinel 。
• Sentinel 發送的資訊中還包括完整的主伺服器目前配置（configuration）。 如果一個 Sentinel 包含的主伺服器配置比另一個 Sentinel 發送的配置要舊， 那麼這個 Sentinel 會立即更新到新配置上。
• 在将一個新 Sentinel 添加到監視主伺服器的清單上面之前， Sentinel 會先檢查清單中是否已經包含了和要添加的 Sentinel 擁有相同運作 ID 或者相同位址（包括 IP 位址和端口号）的 Sentinel ， 如果是的話， Sentinel 會先移除清單中已有的那些擁有相同運作 ID 或者相同位址的 Sentinel ， 然後再添加新 Sentinel 。

Sentinel API

在預設情況下， Sentinel 使用 TCP 端口 26379 （普通 Redis 伺服器使用的是 6379 ）。

Sentinel 接受 Redis 協定格式的指令請求， 是以你可以使用 redis-cli 或者任何其他 Redis 用戶端來與 Sentinel 進行通訊。

有兩種方式可以和 Sentinel 進行通訊：

• 第一種方法是通過直接發送指令來查詢被監視 Redis 伺服器的目前狀态， 以及 Sentinel 所知道的關于其他 Sentinel 的資訊， 諸如此類。
• 另一種方法是使用釋出與訂閱功能， 通過接收 Sentinel 發送的通知： 當執行故障轉移操作， 或者某個被監視的伺服器被判斷為主觀下線或者客觀下線時， Sentinel 就會發送相應的資訊。

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 會向其他 Sentinel 發送一個新的配置，其他 Sentinel 會根據這個配置進行相應的更新）。

釋出與訂閱資訊

用戶端可以将 Sentinel 看作是一個隻提供了訂閱功能的 Redis 伺服器： 你不可以使用 PUBLISH 指令向這個伺服器發送資訊， 但你可以用SUBSCRIBE 指令或者 PSUBSCRIBE 指令， 通過訂閱給定的頻道來擷取相應的事件提醒。

一個頻道能夠接收和這個頻道的名字相同的事件。 比如說， 名為 +sdown 的頻道就可以接收所有執行個體進入主觀下線（SDOWN）狀态的事件。

通過執行 PSUBSCRIBE * 指令可以接收所有事件資訊。

以下列出的是用戶端可以通過訂閱來獲得的頻道和資訊的格式： 第一個英文單詞是頻道/事件的名字， 其餘的是資料的格式。

注意， 當格式中包含 instance details 字樣時， 表示頻道所傳回的資訊中包含了以下用于識别目标執行個體的内容：

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

@ 字元之後的内容用于指定主伺服器， 這些内容是可選的， 它們僅在 @ 字元之前的内容指定的執行個體不是主伺服器時使用。

• +reset-master <instance details> ：主伺服器已被重置。
• +slave <instance details> ：一個新的從伺服器已經被 Sentinel 識别并關聯。
• +failover-state-reconf-slaves <instance details> ：故障轉移狀态切換到了 reconf-slaves 狀态。
• +failover-detected <instance details> ：另一個 Sentinel 開始了一次故障轉移操作，或者一個從伺服器轉換成了主伺服器。
• +slave-reconf-sent <instance details> ：領頭（leader）的 Sentinel 向執行個體發送了 SLAVEOF 指令，為執行個體設定新的主伺服器。
• +slave-reconf-inprog <instance details> ：執行個體正在将自己設定為指定主伺服器的從伺服器，但相應的同步過程仍未完成。
• +slave-reconf-done <instance details> ：從伺服器已經成功完成對新主伺服器的同步。
• -dup-sentinel <instance details> ：對給定主伺服器進行監視的一個或多個 Sentinel 已經因為重複出現而被移除 —— 當 Sentinel 執行個體重新開機的時候，就會出現這種情況。
• +sentinel <instance details> ：一個監視給定主伺服器的新 Sentinel 已經被識别并添加。
• +sdown <instance details> ：給定的執行個體現在處于主觀下線狀态。
• -sdown <instance details> ：給定的執行個體已經不再處于主觀下線狀态。
• +odown <instance details> ：給定的執行個體現在處于客觀下線狀态。
• -odown <instance details> ：給定的執行個體已經不再處于客觀下線狀态。
• +new-epoch <instance details> ：目前的紀元（epoch）已經被更新。
• +try-failover <instance details> ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by the majority）。
• +elected-leader <instance details> ：赢得指定紀元的選舉，可以進行故障遷移操作了。
• +failover-state-select-slave <instance details> ：故障轉移操作現在處于 select-slave 狀态 —— Sentinel 正在尋找可以更新為主伺服器的從伺服器。
• no-good-slave <instance details> ：Sentinel 操作未能找到适合進行更新的從伺服器。Sentinel 會在一段時間之後再次嘗試尋找合适的從伺服器來進行更新，又或者直接放棄執行故障轉移操作。
• selected-slave <instance details> ：Sentinel 順利找到适合進行更新的從伺服器。
• failover-state-send-slaveof-noone <instance details> ：Sentinel 正在将指定的從伺服器更新為主伺服器，等待更新功能完成。
• failover-end-for-timeout <instance details> ：故障轉移因為逾時而中止，不過最終所有從伺服器都會開始複制新的主伺服器（slaves will eventually be configured to replicate with the new master anyway）。
• failover-end <instance details> ：故障轉移操作順利完成。所有從伺服器都開始複制新的主伺服器了。
• +switch-master <master name> <oldip> <oldport> <newip> <newport> ：配置變更，主伺服器的 IP 和位址已經改變。 這是絕大多數外部使用者都關心的資訊。
• +tilt ：進入 tilt 模式。
• -tilt ：退出 tilt 模式。

故障轉移

一次故障轉移操作由以下步驟組成：

• 發現主伺服器已經進入客觀下線狀态。
• 對我們的目前紀元進行自增（詳情請參考 Raft leader election ）， 并嘗試在這個紀元中當選。
• 如果當選失敗， 那麼在設定的故障遷移逾時時間的兩倍之後， 重新嘗試當選。 如果當選成功， 那麼執行以下步驟。
• 選出一個從伺服器，并将它更新為主伺服器。
• 向被選中的從伺服器發送 SLAVEOF NO ONE 指令，讓它轉變為主伺服器。
• 通過釋出與訂閱功能， 将更新後的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進行更新。
• 向已下線主伺服器的從伺服器發送 SLAVEOF 指令， 讓它們去複制新的主伺服器。
• 當所有從伺服器都已經開始複制新的主伺服器時， 領頭 Sentinel 終止這次故障遷移操作。

每當一個 Redis 執行個體被重新配置（reconfigured） —— 無論是被設定成主伺服器、從伺服器、又或者被設定成其他主伺服器的從伺服器 —— Sentinel 都會向被重新配置的執行個體發送一個 CONFIG REWRITE 指令， 進而確定這些配置會持久化在硬碟裡。

Sentinel 使用以下規則來選擇新的主伺服器：

• 在失效主伺服器屬下的從伺服器當中， 那些被标記為主觀下線、已斷線、或者最後一次回複 PING 指令的時間大于五秒鐘的從伺服器都會被淘汰。
• 在失效主伺服器屬下的從伺服器當中， 那些與失效主伺服器連接配接斷開的時長超過 down-after 選項指定的時長十倍的從伺服器都會被淘汰。
• 在經曆了以上兩輪淘汰之後剩下來的從伺服器中， 我們選出複制偏移量（replication offset）最大的那個從伺服器作為新的主伺服器； 如果複制偏移量不可用， 或者從伺服器的複制偏移量相同， 那麼帶有最小運作 ID 的那個從伺服器成為新的主伺服器。

Sentinel 自動故障遷移的一緻性特質

Sentinel 自動故障遷移使用 Raft 算法來選舉領頭（leader） Sentinel ， 進而確定在一個給定的紀元（epoch）裡， 隻有一個領頭産生。

這表示在同一個紀元中， 不會有兩個 Sentinel 同時被選中為領頭， 并且各個 Sentinel 在同一個紀元中隻會對一個領頭進行投票。

更高的配置紀元總是優于較低的紀元， 是以每個 Sentinel 都會主動使用更新的紀元來代替自己的配置。

簡單來說， 我們可以将 Sentinel 配置看作是一個帶有版本号的狀态。 一個狀态會以最後寫入者勝出（last-write-wins）的方式（也即是，最新的配置總是勝出）傳播至所有其他 Sentinel 。

舉個例子， 當出現網絡分割（network partitions）時， 一個 Sentinel 可能會包含了較舊的配置， 而當這個 Sentinel 接到其他 Sentinel 發來的版本更新的配置時， Sentinel 就會對自己的配置進行更新。

如果要在網絡分割出現的情況下仍然保持一緻性， 那麼應該使用 min-slaves-to-write 選項， 讓主伺服器在連接配接的從執行個體少于給定數量時停止執行寫操作， 與此同時， 應該在每個運作 Redis 主伺服器或從伺服器的機器上運作 Redis Sentinel 程序。

Sentinel 狀态的持久化

Sentinel 的狀态會被持久化在 Sentinel 配置檔案裡面。

每當 Sentinel 接收到一個新的配置， 或者當領頭 Sentinel 為主伺服器建立一個新的配置時， 這個配置會與配置紀元一起被儲存到磁盤裡面。

這意味着停止和重新開機 Sentinel 程序都是安全的。

Sentinel 在非故障遷移的情況下對執行個體進行重新配置

即使沒有自動故障遷移操作在進行， Sentinel 總會嘗試将目前的配置設定到被監視的執行個體上面。 特别是：

• 根據目前的配置， 如果一個從伺服器被宣告為主伺服器， 那麼它會代替原有的主伺服器， 成為新的主伺服器， 并且成為原有主伺服器的所有從伺服器的複制對象。
• 那些連接配接了錯誤主伺服器的從伺服器會被重新配置， 使得這些從伺服器會去複制正确的主伺服器。

不過， 在以上這些條件滿足之後， Sentinel 在對執行個體進行重新配置之前仍然會等待一段足夠長的時間， 確定可以接收到其他 Sentinel 發來的配置更新， 進而避免自身因為儲存了過期的配置而對執行個體進行了不必要的重新配置。

TILT 模式

Redis Sentinel 嚴重依賴計算機的時間功能： 比如說， 為了判斷一個執行個體是否可用， Sentinel 會記錄這個執行個體最後一次相應 PING 指令的時間， 并将這個時間和目前時間進行對比， 進而知道這個執行個體有多長時間沒有和 Sentinel 進行任何成功通訊。

不過， 一旦計算機的時間功能出現故障， 或者計算機非常忙碌， 又或者程序因為某些原因而被阻塞時， Sentinel 可能也會跟着出現故障。

TILT 模式是一種特殊的保護模式： 當 Sentinel 發現系統有些不對勁時， Sentinel 就會進入 TILT 模式。

因為 Sentinel 的時間中斷器預設每秒執行 10 次， 是以我們預期時間中斷器的兩次執行之間的間隔為 100 毫秒左右。 Sentinel 的做法是， 記錄上一次時間中斷器執行時的時間， 并将它和這一次時間中斷器執行的時間進行對比：

• 如果兩次調用時間之間的差距為負值， 或者非常大（超過 2 秒鐘）， 那麼 Sentinel 進入 TILT 模式。
• 如果 Sentinel 已經進入 TILT 模式， 那麼 Sentinel 延遲退出 TILT 模式的時間。

當 Sentinel 進入 TILT 模式時， 它仍然會繼續監視所有目标， 但是：

• 它不再執行任何操作，比如故障轉移。
• 當有執行個體向這個 Sentinel 發送 SENTINEL is-master-down-by-addr 指令時， Sentinel 傳回負值： 因為這個 Sentinel 所進行的下線判斷已經不再準确。

如果 TILT 可以正常維持 30 秒鐘， 那麼 Sentinel 退出 TILT 模式。

處理 -BUSY 狀态

該功能尚未實作

Sentinel 的用戶端實作