Redis Sentinel：叢集Failover解決方案
- ##redis.conf
- ##redis-0,預設為master
- port 6379
- ##授權密碼，請各個配置保持一致
- requirepass 012_345^678-90
- masterauth 012_345^678-90
- ##暫且禁用指令重新命名
- ##rename-command
- ##開啟AOF，禁用snapshot
- appendonly yes
- save “”
- ##slaveof no one
- slave-read-only yes
- ##redis.conf
- ##redis-1,通過啟動引數配置為slave，配置檔案保持獨立
-
port 6579
- slaveof 127.0.0.16379
- ##-----------其他配置和master保持一致-----------##
2) sentinel.conf
請首先在各個redis服務中sentinel.conf同目錄下新建local-sentinel.conf,並將複製如下配置資訊.
- ##redis-0
- ##sentinel例項之間的通訊埠
- port 26379
- sentinel monitor def_master 127.0.0.163792
- sentinel auth-pass def_master 012_345^678-90
-
sentinel down-after-milliseconds def_master 30000
- sentinel can-failover def_master yes
- sentinel parallel-syncs def_master 1
- sentinel failover-timeout def_master 900000
- ##redis-1
- port 26479
- ##--------其他配置同上-------##
- ##redis-2
- port 26579
- ##--------其他配置同上-------#
3) 啟動與檢測
Java程式碼
- ##redis-0(預設為master)
- > ./redis-server --include ../redis.conf
- ##啟動sentinel元件
- > ./redis-sentinel ../local-sentinel.conf
此後你可以使用任意一個"redis-cli"視窗,輸入"INFO"命令,可以檢視當前server的狀態:
- > ./redis-cli -h 127.0.0.1 -p 6379
- ##如下為列印資訊摘要:
- #Replication
- role:master
- connected_salves:2
- slave0:127.0.0.1,6479,online
- slave1:127.0.0.1.6579,online
"INFO"指令不僅可以幫助我們獲得叢集的情況,當然sentinel元件也是使用"INFO"做同樣的事情.
當上述部署環境穩定後,我們直接關閉redis-0,在等待"down-after-milliseconds"秒之後(30秒),redis-0/redis-1/redis-2的sentinel視窗會立即列印"+sdown""+odown""+failover""+selected-slave""+promoted-slave""+slave-reconf"等等一系列指令,這些指令標明當master失效後,sentinel元件進行failover的過程.
當環境再次穩定後,我們發現,redis-1被提升("promoted")為master,且redis-2也通過"slave-reconf"過程之後跟隨了redis-1.
如果此後想再次讓redis-0加入叢集,你需要首先通過"INFO"指令找到當前的masterip + port,並在啟動指令中明確指明slaveof引數:
- > ./redis-server --include ../redis.conf --slaveof 127.0.0.16479
sentinel例項需要全程處於啟動狀態,如果只啟動server而不啟動相應的sentinel,仍然不能確保server能夠正確的被監控和管理.
二. sentinel原理
首先解釋2個名詞:SDOWN和ODOWN.
- SDOWN:subjectively down,直接翻譯的為"主觀"失效,即當前sentinel例項認為某個redis服務為"不可用"狀態.
- ODOWN:objectively down,直接翻譯為"客觀"失效,即多個sentinel例項都認為master處於"SDOWN"狀態,那麼此時master將處於ODOWN,ODOWN可以簡單理解為master已經被叢集確定為"不可用",將會開啟failover.
SDOWN適合於master和slave,但是ODOWN只會使用於master;當slave失效超過"down-after-milliseconds"後,那麼所有sentinel例項都會將其標記為"SDOWN".
1) SDOWN與ODOWN轉換過程:
- 每個sentinel例項在啟動後,都會和已知的slaves/master以及其他sentinels建立TCP連線,並週期性傳送PING(預設為1秒)
- 在互動中,如果redis-server無法在"down-after-milliseconds"時間內響應或者響應錯誤資訊,都會被認為此redis-server處於SDOWN狀態.
- 如果2)中SDOWN的server為master,那麼此時sentinel例項將會向其他sentinel間歇性(一秒)傳送"is-master-down-by-addr <ip> <port>"指令並獲取響應資訊,如果足夠多的sentinel例項檢測到master處於SDOWN,那麼此時當前sentinel例項標記master為ODOWN...其他sentinel例項做同樣的互動操作.配置項"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果檢測到master處於SDOWN狀態的slave個數達到<quorum>,那麼此時此sentinel例項將會認為master處於ODOWN.
- 每個sentinel例項將會間歇性(10秒)向master和slaves傳送"INFO"指令,如果master失效且沒有新master選出時,每1秒傳送一次"INFO";"INFO"的主要目的就是獲取並確認當前叢集環境中slaves和master的存活情況.
- 經過上述過程後,所有的sentinel對master失效達成一致後,開始failover.
2) Sentinel與slaves"自動發現"機制:
在sentinel的配置檔案中(local-sentinel.conf),都指定了port,此port就是sentinel例項偵聽其他sentinel例項建立連結的埠.在叢集穩定後,最終會每個sentinel例項之間都會建立一個tcp連結,此連結中傳送"PING"以及類似於"is-master-down-by-addr"指令集,可用用來檢測其他sentinel例項的有效性以及"ODOWN"和"failover"過程中資訊的互動.
在sentinel之間建立連線之前,sentinel將會盡力和配置檔案中指定的master建立連線.sentinel與master的連線中的通訊主要是基於pub/sub來發布和接收資訊,釋出的資訊內容包括當前sentinel例項的偵聽埠:
- +sentinel sentinel 127.0.0.1:26579127.0.0.126579 ....
釋出的主題名稱為"__sentinel__:hello";同時sentinel例項也是"訂閱"此主題,以獲得其他sentinel例項的資訊.由此可見,環境首次構建時,在預設master存活的情況下,所有的sentinel例項可以通過pub/sub即可獲得所有的sentinel資訊,此後每個sentinel例項即可以根據+sentinel資訊中的"ip+port"和其他sentinel逐個建立tcp連線即可.不過需要提醒的是,每個sentinel例項均會間歇性(5秒)向"__sentinel__:hello"主題中釋出自己的ip+port,目的就是讓後續加入叢集的sentinel例項也能或得到自己的資訊.
根據上文,我們知道在master有效的情況下,即可通過"INFO"指令獲得當前master中已有的slave列表;此後任何slave加入叢集,master都會向"主題中"釋出"+slave 127.0.0.1:6579 ..",那麼所有的sentinel也將立即獲得slave資訊,並和slave建立連結並通過PING檢測其存活性.
補充一下,每個sentinel例項都會儲存其他sentinel例項的列表以及現存的master/slaves列表,各自的列表中不會有重複的資訊(不可能出現多個tcp連線),對於sentinel將使用ip+port做唯一性標記,對於master/slaver將使用runid做唯一性標記,其中redis-server的runid在每次啟動時都不同.
3) Leader選舉:
其實在sentinels故障轉移中，仍然需要一個“Leader”來排程整個過程：master的選舉以及slave的重配置和同步。當叢集中有多個sentinel例項時，如何選舉其中一個sentinel為leader呢？
在配置檔案中“can-failover”“quorum”引數，以及“is-master-down-by-addr”指令配合來完成整個過程。
A) “can-failover”用來表明當前sentinel是否可以參與“failover”過程，如果為“YES”則表明它將有能力參與“Leader”的選舉，否則它將作為“Observer”，observer參與leader選舉投票但不能被選舉；
B) “quorum”不僅用來控制master ODOWN狀態確認，同時還用來選舉leader時最小“贊同票”數；
C) “is-master-down-by-addr”，在上文中以及提到，它可以用來檢測“ip + port”的master是否已經處於SDOWN狀態，不過此指令不僅能夠獲得master是否處於SDOWN，同時它還額外的返回當前sentinel本地“投票選舉”的Leader資訊(runid);
每個sentinel例項都持有其他的sentinels資訊，在Leader選舉過程中(當為leader的sentinel例項失效時，有可能master server並沒失效，注意分開理解)，sentinel例項將從所有的sentinels集合中去除“can-failover = no”和狀態為SDOWN的sentinels，在剩餘的sentinels列表中按照runid按照“字典”順序排序後，取出runid最小的sentinel例項，並將它“投票選舉”為Leader，並在其他sentinel傳送的“is-master-down-by-addr”指令時將推選的runid追加到響應中。每個sentinel例項都會檢測“is-master-down-by-addr”的響應結果，如果“投票選舉”的leader為自己，且狀態正常的sentinels例項中，“贊同者”的自己的sentinel個數不小於(>=) 50% + 1,且不小與<quorum>，那麼此sentinel就會認為選舉成功且leader為自己。
在sentinel.conf檔案中，我們期望有足夠多的sentinel例項配置“can-failover yes”，這樣能夠確保當leader失效時，能夠選舉某個sentinel為leader，以便進行failover。如果leader無法產生，比如較少的sentinels例項有效，那麼failover過程將無法繼續.
4) failover過程:
在Leader觸發failover之前，首先wait數秒(隨即0~5)，以便讓其他sentinel例項準備和調整(有可能多個leader??),如果一切正常，那麼leader就需要開始將一個salve提升為master，此slave必須為狀態良好(不能處於SDOWN/ODOWN狀態)且權重值最低(redis.conf中)的，當master身份被確認後，開始failover
A）“+failover-triggered”: Leader開始進行failover，此後緊跟著“+failover-state-wait-start”，wait數秒。
B）“+failover-state-select-slave”: Leader開始查詢合適的slave
C）“+selected-slave”: 已經找到合適的slave
D） “+failover-state-sen-slaveof-noone”: Leader向slave傳送“slaveof no one”指令，此時slave已經完成角色轉換，此slave即為master
E） “+failover-state-wait-promotition”: 等待其他sentinel確認slave
F）“+promoted-slave”：確認成功
G）“+failover-state-reconf-slaves”: 開始對slaves進行reconfig操作。
H）“+slave-reconf-sent”:向指定的slave傳送“slaveof”指令，告知此slave跟隨新的master
I）“+slave-reconf-inprog”: 此slave正在執行slaveof + SYNC過程，如過slave收到“+slave-reconf-sent”之後將會執行slaveof操作。
J）“+slave-reconf-done”: 此slave同步完成，此後leader可以繼續下一個slave的reconfig操作。迴圈G）
K）“+failover-end”: 故障轉移結束
L）“+switch-master”：故障轉移成功後，各個sentinel例項開始監控新的master。