redis之哨兵
之前我們已經學過了主從複製了,那麼如果遇到這種情況該怎麼辦?
複製架構中出現宕機情況,怎麼辦?
如果在主從複製架構中出現宕機的情況,需要分情況看:
- 從Redis宕機
- 這個相對而言比較簡單,在Redis中從庫重新啟動後會自動加入到主從架構中,自動完成同步資料;
- 問題? 如果從庫在斷開期間,主庫的變化不大,從庫再次啟動後,主庫依然會將所有的資料做RDB操作嗎?還是增量更新?(從庫有做持久化的前提下)
- 不會的,因為在Redis2.8版本後就實現了,主從斷線後恢復的情況下實現增量複製。
- 主Redis宕機
- 這個相對而言就會複雜一些,需要以下2步才能完成
- 第一步,在從資料庫中執行SLAVEOF NO ONE命令,斷開主從關係並且提升為主庫繼續服務;
- 第二步,將主庫重新啟動後,執行SLAVEOF命令,將其設定為其他庫的從庫,這時資料就能更新回來;
- 第一步,在從資料庫中執行SLAVEOF NO ONE命令,斷開主從關係並且提升為主庫繼續服務;
- 這個手動完成恢復的過程其實是比較麻煩的並且容易出錯,有沒有好辦法解決呢?當前有的,Redis提供的哨兵(sentinel)的功能。
- 這個相對而言就會複雜一些,需要以下2步才能完成
接下來就介紹一下哨兵。
一、 哨兵(sentinel)
顧名思義,哨兵的作用就是對Redis的系統的執行情況的監控,它是一個獨立程序。它的功能有2個:
- 監控主資料庫和從資料庫是否執行正常;
- 主資料出現故障後自動將從資料庫轉化為主資料庫;
1.1 原理
單個哨兵的架構:
多個哨兵的架構:
多個哨兵,不僅同時監控主從資料庫,而且哨兵之間互為監控。
1.2 環境
當前處於一主多從的環境中: 輸入info replication 檢視主從配置關係
192.168.19.26:6379> info replication # Replicationrole:master connected_slaves:2 slave0:ip=192.168.19.26,port=6380,state=online,offset=4088,lag=0 slave1:ip=192.168.19.26,port=6381,state=online,offset=4088,lag=1
1.3 配置哨兵
啟動哨兵程序首先需要建立哨兵配置檔案:
vi sentinel.conf(自己建立的)
輸入內容:
sentinel monitor myMaster 192.168.19.26 6379 1
說明:
myMaster:監控主資料的名稱,自定義即可。
192.168.19.26:監控的主資料庫的IP
6379:監控的主資料庫的埠
1:最低通過票數
啟動哨兵程序:
redis-sentinel ./sentinel.conf
哨兵無需配置slave,只需要指定master,哨兵會自動發現slave
二、從資料庫宕機
kill掉從redis程序後,30秒後哨兵的控制檯輸出:
2989:X 05 Jun 20:09:33.509 # +sdown slave 192.168.19.26:6380 192.168.19.26 6380 @ myMaster 192.168.19.26 6379
說明已經監控到slave宕機了,那麼,如果我們將6380埠的redis例項啟動後,會自動加入到主從複製嗎?
2989:X 05 Jun 20:13:22.716 * +reboot slave 192.168.19.26:6380 192.168.19.26 6380 @ myMaster 192.168.19.26 6379
2989:X 05 Jun 20:13:22.788 # -sdown slave 192.168.19.26:6380 192.168.19.26 6380 @ myMaster 192.168.19.26 6379
可以看出,slave從新加入到了主從複製中。-sdown:說明是恢復服務。
三、 主庫宕機
哨兵控制檯打印出如下資訊:
2989:X 05 Jun 20:16:50.300 # +sdown master ttMaster 127.0.0.1 6379 說明master服務已經宕機
2989:X 05 Jun 20:16:50.300 # +odown master ttMaster 127.0.0.1 6379 #quorum 1/1
2989:X 05 Jun 20:16:50.300 # +new-epoch 1
2989:X 05 Jun 20:16:50.300 # +try-failover master ttMaster 127.0.0.1 6379 開始恢復故障
2989:X 05 Jun 20:16:50.304 # +vote-for-leader 9059917216012421e8e89a4aa02f15b75346d2b7 1 投票選舉哨兵leader,現在就一個哨兵所以leader就自己
2989:X 05 Jun 20:16:50.304 # +elected-leader master myMaster 127.0.0.1 6379 選中leader
2989:X 05 Jun 20:16:50.304 # +failover-state-select-slave master myMaster 127.0.0.1 6379 選中其中的一個slave當做master
2989:X 05 Jun 20:16:50.357 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myMaster 127.0.0.1 6379 選中6381
2989:X 05 Jun 20:16:50.357 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ myMaster 127.0.0.1 6379 傳送slaveof no one命令
2989:X 05 Jun 20:16:50.420 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ myMaster 127.0.0.1 6379 等待升級master
2989:X 05 Jun 20:16:50.515 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myMaster 127.0.0.1 6379 升級6381為master
2989:X 05 Jun 20:16:50.515 # +failover-state-reconf-slaves master ttMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:50.566 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ myMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:51.333 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ myMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:52.382 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ myMaster 127.0.0.1 6379
2989:X 05 Jun 20:16:52.438 # +failover-end master ttMaster 127.0.0.1 6379 故障恢復完成
2989:X 05 Jun 20:16:52.438 # +switch-master ttMaster 127.0.0.1 6379 127.0.0.1 6381 主資料庫從6379轉變為6381
2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myMaster 127.0.0.1 6381 新增6380為6381的從庫
2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ ttMaster 127.0.0.1 6381 新增6379為6381的從庫
2989:X 05 Jun 20:17:22.463 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ ttMaster 127.0.0.1 6381 發現6379已經宕機,等待6379的恢復
可以看出,目前,6381為master,擁有一個slave為6380.
接下來,我們恢復6379檢視狀態:
2989:X 05 Jun 20:35:32.172 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myMaster 127.0.0.1 6381 6379已經恢復服務
2989:X 05 Jun 20:35:42.137 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myMaster 127.0.0.1 6381 將6379設定為6381的slave