redis高可用之REDIS SENTINEL

時間 2019-12-06

標籤 redis 用之 sentinel 欄目 Redis 简体版

原文原文鏈接

1. Redis主從配置

1.1. 設置主從複製

Master <= Salveredis

10.24.6.5:6379 <= 10.24.6.7:6379服務器

1.2. 取消主從複製

1.3. 刪除全部數據

flushdb:刪除這個db下的。
flushall:刪除全部socket

2. Sentinel高可用配置

Sentinel服務器地址:tcp

10.24.6.7翻譯

啓動3d

Redis-sentinel sentinel.confserver

或者blog

Redis-server sentinel.conf –sentinel排序

Redis服務器:ip

Master <= Salve

10.24.6.5:6379 <= 10.24.6.7:6379

10.24.6.4:6379

10.24.6.6:6379

2.1. Sentinel客戶端:

2.1.1. Redis-DeskopMaster

2.1.2. Redis-cli

2.2. 查看Sentinel(info)

2.3. 添加redis sentinel

有兩種方式，一種是經過配置文件，如何配置參考附錄的sentinel.conf。這種方式主要是面向預配置的redis羣集。

另一種方式使用redis-cli作熱配置：

127.0.0.1:26381> sentinel monitor mymaster 172.18.18.207 6501 1 OK

命令的格式以下：

SENTINEL MONITOR <name> <ip> <port> <quorum>

注：quorum表示發起failover須要的sentinel數量，看sentinel羣集的數量決定。

2.4. 刪除redis sentinel

從sentinel中刪除羣集，命令： 172.18.18.207:26381> sentinel remove mymaster OK

2.5. Sentinel高可用管理

2.5.1. 查看全部master

2.5.2. 查看master的slave

2.6. Sentinel高可用客戶端選擇服務

from redis.sentinel import Sentinel
sentinel = Sentinel([('10.24.6.7', 26379)], socket_timeout=0.1)
master = sentinel.master_for('10.24.6.5master', socket_timeout=0.1)
print master
master.set('foo', 'bar')
print master.get('foo')

2.7. 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:26579 127.0.0.1 26579 ....

發佈的主題名稱爲"__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。