Redis高可用之Redis Sentinel

Redis高可用之Redis Sentinel
1. Redis主從配置1.1. 設定主從複製

Master <= Salve

10.24.6.5:6379 <= 10.24.6.7:6379

 

 

1.2.   取消主從複製

 

 

1.3.  刪除所有資料

flushdb:刪除這個db下的。
flushall:刪除所有

 

2. Sentinel高可用配置

Sentinel伺服器位址:

10.24.6.7

啟動

Redis-sentinel sentinel.conf

或者

Redis-server sentinel.conf –sentinel

 

Redis伺服器:

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執行個體的偵聽連接埠:

1. +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。

Sentinel.conf詳解

1. ##sentinel執行個體之間的通訊連接埠 
2. ##redis-0 
3. port 26379 
4. ##sentinel需要監控的master資訊：<mastername> <masterIP> <masterPort> <quorum> 
5. ##<quorum>應該小於叢集中slave的個數,只有當至少<quorum>個sentinel執行個體提交"master失效" 
6. ##才會認為master為O_DWON("客觀"失效) 
7. sentinel monitor def_master 127.0.0.1 6379 2 
8. sentinel auth-pass def_master 012_345^678-90 
9. ##master被當前sentinel執行個體認定為“失效”的間隔時間 
10. ##如果當前sentinel與master直接的通訊中，在指定時間內沒有響應或者響應錯誤碼，那麼 
11. ##當前sentinel就認為master失效(SDOWN，“主觀”失效) 
12. ##<mastername> <millseconds> 
13. ##預設為30秒 
14. sentinel down-after-milliseconds def_master 30000 
15.  
16. ##當前sentinel執行個體是否允許實施“failover”(容錯移轉) 
17. ##no表示當前sentinel為“觀察者”(只參與"投票".不參與實施failover)， 
18. ##全域中至少有一個為yes 
19. sentinel can-failover def_master yes 
20.  
21. ##當新master產生時，同時進行“slaveof”到新master並進行“SYNC”的slave個數。 
22. ##預設為1,建議保持預設值 
23. ##在salve執行salveof與同步時，將會終止用戶端請求。 
24. ##此值較大，意味著“叢集”終止用戶端請求的時間總和和較大。 
25. ##此值較小,意味著“叢集”在容錯移轉期間，多個salve向用戶端提供服務時仍然使用舊資料。 
26. sentinel parallel-syncs def_master 1 
27.  
28. ##failover到期時間，當failover開始後，在此時間內仍然沒有觸發任何failover操作， 
29. ##當前sentinel將會認為此次failoer失敗。 
30. sentinel failover-timeout def_master 900000 
31.  
32. ##當failover時，可以指定一個“通知”指令碼用來告知系統管理員，當前叢集的情況。 
33. ##指令碼被允許執行的最大時間為60秒，如果逾時，指令碼將會被終止(KILL) 
34. ##指令碼執行的結果： 
35. ## 1    -> 稍後重試，最大重試次數為10;   
36. ## 2    -> 執行結束，無需重試 
37. ##sentinel notification-script mymaster /var/redis/notify.sh 
38. ##failover之後重配置用戶端，執行指令碼時會傳遞大量參數，請參考相關文檔 
39. # sentinel client-reconfig-script <master-name> <script-path>

下面關於Redis的文章您也可能喜歡，不妨參考下：

Ubuntu 14.04下Redis安裝及簡單測試

Redis主從複製基本配置

Redis叢集明細文檔

Ubuntu 12.10下安裝Redis（圖文詳解）+ Jedis串連Redis

Redis系列-安裝部署維護篇

CentOS 6.3安裝Redis

Redis安裝部署學習筆記

Redis設定檔redis.conf 詳解

Redis 的詳細介紹：請點這裡
Redis 的：請點這裡

本文永久更新連結地址：