1、Redis Sentinel服務配置

1.1簡介

Redis 的 Sentinel 系統(tǒng)用于管理多個 Redis 服務器（instance）， 該系統(tǒng)執(zhí)行以下三個任務：

監(jiān)控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。

提醒（Notification）： 當被監(jiān)控的某個 Redis 服務器出現問題時， Sentinel 可以通過API 向管理員或者其他應用程序發(fā)送通知。

自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 并讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

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

雖然 Redis Sentinel 釋出為一個單獨的可執(zhí)行文件 redis-sentinel ， 但實際上它只是一個運行在特殊模式下的 Redis 服務器， 你可以在啟動一個普通 Redis 服務器時通過給定 --sentinel 選項來啟動Redis Sentinel 。

1.2相關配置

案例：

如果要監(jiān)控兩個redis實例，可以進行如下配置Redis安裝目錄下sentinel.conf文件：

常規(guī)配置：

port 26379

daemonize yes

logfile "/var/log/redis/sentinel.log"

#master 7000

sentinel monitor master1 127.0.0.1 7000 2                #配置master名、ip、port、需要多少個sentinel才能判斷[客觀下線]（2）

sentinel down-after-milliseconds master-7000 30000      #配置sentinel向master發(fā)出ping，最大響應時間、超過則認為主觀下線

sentinel parallel-syncs master-7000 1                   #配置在進行故障轉移時，運行多少個slave進行數據備份同步(越少速度越快)

sentinel failover-timeout master-7000 180000            #配置當出現failover時下一個sentinel與上一個sentinel對[同一個master監(jiān)測的時間間隔](最后設置為客觀下線)
 

#master 7001

sentinel monitor master2 127.0.0.1 7001 1

sentinel down-after-milliseconds master-7001 30000

sentinel parallel-syncs master-7001 1

sentinel failover-timeout master-7001 180000

特殊配置：

min-slaves-to-write 1

min-slaves-max-lag 10

通過上面的配置，當一個redis是master時，如果它不能向至少一個slave寫數據(上面的min-slaves-to-write指定了slave的數量)，它將會拒絕接受客戶端的寫請求。由于復制是異步的，master無法向slave寫數據意味著slave要么斷開連接了，要么不在指定時間內向master發(fā)送同步數據的請求了(上面的min-slaves-max-lag指定了這個時間)。

1.3 相關術語說明

Sentinel包括兩個重要的術語：主觀下線和客觀下線>

1. 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。

2. 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 并且通過SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。

客觀下線條件只適用于主服務器： 對于任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。

只要一個 Sentinel 發(fā)現某個主服務器進入了客觀下線狀態(tài)， 這個Sentinel 就可能會被其他 Sentinel 推選出， 并對失效的主服務器執(zhí)行自動故障遷移操作。

每個Sentinel實例都執(zhí)行的定時任務

1. 每個Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發(fā)送一個 PING 命令。

2. 如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實例會被 Sentinel 標記為主觀下線。 一個有效回復可以是： +PONG 、 -LOADING 或者-MASTERDOWN 。

3. 如果一個主服務器被標記為主觀下線， 那么正在監(jiān)視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態(tài)。

4. 如果一個主服務器被標記為主觀下線， 并且有足夠數量的 Sentinel （至少要達到配置文件指定的數量）在指定的時間范圍內同意這一判斷， 那么這個主服務器被標記為客觀下線。

5. 在一般情況下， 每個 Sentinel 會以每10 秒一次的頻率向它已知的所有主服務器和從服務器發(fā)送 INFO 命令。 當一個主服務器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務器的所有從服務器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次。

6. 當沒有足夠數量的 Sentinel 同意主服務器已經下線， 主服務器的客觀下線狀態(tài)就會被移除。 當主服務器重新向 Sentinel 的 PING 命令返回有效回復時， 主服務器的主管下線狀態(tài)就會被移除。

1.4服務日志說明

Sentinel服務啟動后會打印一些相關日志信息，以下是相關日志特殊字符說明：

+reset-master instance details> ：主服務器已被重置。

+slave instance details> ：一個新的從服務器已經被 Sentinel 識別并關聯。

+failover-state-reconf-slaves instancedetails> ：故障轉移狀態(tài)切換到了reconf-slaves 狀態(tài)。

+failover-detected instance details>：另一個 Sentinel 開始了一次故障轉移操作，或者一個從服務器轉換成了主服務器。

+slave-reconf-sent instance details>：領頭（leader）的 Sentinel 向實例發(fā)送了 SLAVEOF 命令，為實例設置新的主服務器。

+slave-reconf-inprog instancedetails> ：實例正在將自己設置為指定主服務器的從服務器，但相應的同步過程仍未完成。

+slave-reconf-done instance details>：從服務器已經成功完成對新主服務器的同步。

-dup-sentinel instance details> ：對給定主服務器進行監(jiān)視的一個或多個 Sentinel 已經因為重復出現而被移除 —— 當 Sentinel 實例重啟的時候，就會出現這種情況。

+sentinel instance details> ：一個監(jiān)視給定主服務器的新 Sentinel 已經被識別并添加。

+sdown instance details> ：給定的實例現在處于主觀下線狀態(tài)。

-sdown instance details> ：給定的實例已經不再處于主觀下線狀態(tài)。

+odown instance details> ：給定的實例現在處于客觀下線狀態(tài)。

-odown instance details> ：給定的實例已經不再處于客觀下線狀態(tài)。

+new-epoch instance details> ：當前的紀元（epoch）已經被更新。

+try-failover instance details> ：一個新的故障遷移操作正在執(zhí)行中，等待被大多數 Sentinel 選中（waiting to be elected by themajority）。

+elected-leader instance details> ：贏得指定紀元的選舉，可以進行故障遷移操作了。

+failover-state-select-slave instancedetails> ：故障轉移操作現在處于select-slave 狀態(tài) —— Sentinel 正在尋找可以升級為主服務器的從服務器。

no-good-slave instance details> ：Sentinel 操作未能找到適合進行升級的從服務器。Sentinel 會在一段時間之后再次嘗試尋找合適的從服務器來進行升級，又或者直接放棄執(zhí)行故障轉移操作。

selected-slave instance details> ：Sentinel 順利找到適合進行升級的從服務器。

failover-state-send-slaveof-nooneinstance details> ：Sentinel 正在將指定的從服務器升級為主服務器，等待升級功能完成。

failover-end-for-timeout instancedetails> ：故障轉移因為超時而中止，不過最終所有從服務器都會開始復制新的主服務器（slaves will eventually be configured to replicate with the newmaster anyway）。

failover-end instance details> ：故障轉移操作順利完成。所有從服務器都開始復制新的主服務器了。

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

+tilt ：進入 tilt 模式。

-tilt ：退出 tilt 模式。

1.5測試驗證

可以對master-slave進行測試，將master關閉，此時slave會自動充當新的new-master；

當old-master恢復后，會充當new-master的slave，即：在這個過程中，sentinel.conf會被改寫，改寫為當前監(jiān)控的主機master服務；

如下圖測試所示：

Master服務停止：

Old-Master恢復服務：

以上這篇Redis Sentinel服務配置流程(詳解)就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持腳本之家。