腳本之家服務器常用軟件

快捷導航

Redis Sentinel服務配置流程(詳解)

更新時間：2017年03月25日 10:31:59 投稿：jingxian

下面小編就為大家?guī)硪黄猂edis Sentinel服務配置流程(詳解)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

1、Redis Sentinel服務配置

1.1簡介

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

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

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

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

Redis Sentinel 是一個分布式系統(tǒng)，你可以在一個架構中運行多個 Sentinel 進程（progress），這些進程使用流言協(xié)議（gossip protocols)來接收關于主服務器是否下線的信息，并使用投票協(xié)議（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 #配置在進行故障轉(zhuǎn)移時，運行多少個slave進行數(shù)據(jù)備份同步(越少速度越快)

sentinel failover-timeout master-7000 180000 #配置當出現(xiàn)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寫數(shù)據(jù)(上面的min-slaves-to-write指定了slave的數(shù)量)，它將會拒絕接受客戶端的寫請求。由于復制是異步的，master無法向slave寫數(shù)據(jù)意味著slave要么斷開連接了，要么不在指定時間內(nèi)向master發(fā)送同步數(shù)據(jù)的請求了(上面的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 在將它們判斷為下線前不需要進行協(xié)商，所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。

只要一個 Sentinel 發(fā)現(xiàn)某個主服務器進入了客觀下線狀態(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. 如果一個主服務器被標記為主觀下線，并且有足夠數(shù)量的 Sentinel （至少要達到配置文件指定的數(shù)量）在指定的時間范圍內(nèi)同意這一判斷，那么這個主服務器被標記為客觀下線。

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

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

1.4服務日志說明

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

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

+slave <instance details> ：一個新的從服務器已經(jīng)被 Sentinel 識別并關聯(lián)。

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

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

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

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

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

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

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

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

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

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

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

+new-epoch <instance details> ：當前的紀元（epoch）已經(jīng)被更新。

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

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

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

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

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

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

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

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

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

+tilt ：進入 tilt 模式。

-tilt ：退出 tilt 模式。

1.5測試驗證

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

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

如下圖測試所示：

Master服務停止：