Docker搭建Redis哨兵模式叢集

• 1、哨兵模式概述
• 2、Docker搭建哨兵模式叢集
• • 2.1 先按照如下連結中方法搭建一個一主二從的Redis叢集，其中redis-master1是主伺服器，redis-salve11和redis-salve22是從伺服器。
  • 2.2 在/root/redisconf/檔案夾下建立sentinel1.conf配置檔案
  • 2.3 建立redis-sentinel1容器(第一個哨兵節點)
  • 2.4 檢視哨兵節點資訊
  • 2.5 建立redis-sentinel2容器(第二個哨兵節點)
• 3、哨兵節點的常用配置
• • 3.1 指定判斷下線時間的門檻值
  • 3.2 設定故障恢複的時效
• 4、哨兵模式下的故障自動恢複效果
• • 4.1 停止主伺服器(redis-master1)所在的容器
  • 4.2 觀察哨兵節點所監控的主從叢集狀态
  • 4.3 觀察redis-slave2所在的指令行視窗，運作`info replication`指令
• 5、通過日志觀察故障恢複流程
• 6、故障節點恢複後的表現

1、哨兵模式概述

  基于主從複制模式的叢集在發生故障時可能會出現資料丢失等情況，因為當主伺服器發生故障後，需要手動進行資料恢複動作，并要重新設定主從關系，比較麻煩。

  可以在主從複制的基礎上引入“哨兵(sentinel)”機制，一方面用哨兵遠端監控主從伺服器是否可用，另一方面當主伺服器發生故障時通過哨兵機制可以實作“故障自動恢複”效果。

一般來說，哨兵機制會和主從複制模式整合使用，在基于哨兵的模式裡會在一台或多台伺服器上引入哨兵程序，這些節點也叫哨兵節點。

  哨兵節點一般不存儲資料，它的作用是監控主從模式裡的主伺服器節點。當哨兵節點監控的主伺服器發生故障時，哨兵節點會主導“故障自動恢複”流程，具體來講就是會在該主伺服器下屬的從伺服器裡選出一個新的主伺服器，并完成響應的資料和配置更改等動作。

  也就是說，如果采用這種模式，可以讓故障自動修複，進而提升系統的可用性。在項目裡，一般會配置多個主從模式叢集，是以會引入多個哨兵節點。基于哨兵模式的叢集效果如下圖所示。

2、Docker搭建哨兵模式叢集

2.1 先按照如下連結中方法搭建一個一主二從的Redis叢集，其中redis-master1是主伺服器，redis-salve11和redis-salve22是從伺服器。

Docker搭建Redis主從複制叢集https://blog.csdn.net/qq_43753724/article/details/120390533?spm=1001.2014.3001.5501

2.2 在/root/redisconf/檔案夾下建立sentinel1.conf配置檔案

檔案内容如下：

port 16379
sentinel monitor master 172.17.0.5 6382 2
dir /
logfile "sentinel1.log"
           

port 16379 哨兵節點的工作端口為16379 sentinel monitor master 172.17.0.5 6382 2

指定監控對象，其中master是哨兵節點為監控伺服器指定的名字，172.17.0.5和6382分别是redis-master1這台主伺服器的IP位址和端口号，最後的2表示至少需要2台哨兵節點認可才能認定該主伺服器失效。

2.3 建立redis-sentinel1容器(第一個哨兵節點)

docker run -itd --privileged=true --name redis-sentinel1 -v /root/redisconf/:/usr/local/etc/redis -p 16379:16379 redis:latest redis-sentinel /usr/local/etc/redis/sentinel1.conf
           

  這裡通過-v挂在了/root/redisconfig/目錄，同時使用-p指定了Docker容器16379端口映射主控端16369端口。這裡用redis-sentinel指令啟動了哨兵節點，啟動時加載了sentinel1.conf檔案。

2.4 檢視哨兵節點資訊

  通過

dodkcer exec -it redis-sentinel1 /bin/bash

指令進入Docker容器裡的指令行，然後用

redis-cli -h 127.0.0.1 -p 16379

指令進入Redis用戶端，在Redis用戶端裡，用

info sentinel

指令檢視哨兵節點的資訊，具體如下：

  從最後一行可以看到，該哨兵節點監控的主伺服器狀态(status)是ok,slaves數量為2，即該主伺服器有兩個從伺服器，這和之前的配置情況是一緻的。

2.5 建立redis-sentinel2容器(第二個哨兵節點)

在/root/redisconf/目錄下建立sentinel2.conf檔案，代碼如下：

port 16380
sentinel monitor master 172.17.0.5 6382 2
dir “/”
logfile "sentinel2.log"
           

随後開啟指令視窗，建立哨兵節點：

docker run -itd --privileged=true --name redis-sentinel2 -v /root/redisconf/:/usr/local/etc/redis -p 16380:16380 redis:latest redis-sentinel /usr/local/etc/redis/sentinel2.conf
           

此時的所有容器

繼續進入用戶端檢視哨兵節點資訊

  可以看到，該哨兵正在監控172.17.0.5:6382指向的主伺服器，sentinels=2表示172.17.0.5:6382指向的主伺服器正在被兩台哨兵節點監控。

  至此，哨兵叢集搭建完成。

3、哨兵節點的常用配置

3.1 指定判斷下線時間的門檻值

sentinel down-after-millseconds master 60000
           

  其中，master表示該哨兵節點監控的伺服器名，需要和sentinel monitor配置項裡指定的伺服器名保持一緻，而60000表示時間，機關是毫秒。也就是說，如果在69秒裡該哨兵節點沒有收到master伺服器的正确響應，就會認為該伺服器已經下線失效。

3.2 設定故障恢複的時效

sentinel failover-timeout master 180000
           

  該時效參數的機關是毫秒，這裡的含義是，在進行故障恢複時，如果在180秒裡還沒有完成主從伺服器的切換動作，就會認為本次恢複動作失敗。

4、哨兵模式下的故障自動恢複效果

  通過上文的配置，能實作哨兵節點監控主從複制模式裡主伺服器的效果。這裡将示範主伺服器失效後故障子u東恢複效果。

4.1 停止主伺服器(redis-master1)所在的容器

  到redis-master1這個Docker容器下，執行

docker stop redis-master1

指令來停止主伺服器所在的容器，以此來模拟主伺服器失效的效果。

4.2 觀察哨兵節點所監控的主從叢集狀态

  到redis-sentinel1這個哨兵節點所在的指令行視窗，通過

info sentinel

指令觀察該哨兵節點所監控的主從叢集狀态。

  從輸出結果可以看到，在該哨兵節點所在的叢集裡，主伺服器已從172.17.0.5：6382換成172.17.0.7:6384。也就是說，真個主從複制叢集并沒有因為主伺服器的失效而終止工作，這裡哨兵節點把從伺服器“提升”為主伺服器，進而讓該主從複制叢集恢複了工作。

  到redis-sentinel2這個哨兵節點所在的指令行視窗，通過info sentinel指令觀察該哨兵節點所監控的主從叢集狀态，也能看到類似的結果。

4.3 觀察redis-slave2所在的指令行視窗，運作

info replication

指令

  從輸出看出role的值已經變為了master,也就是從“從伺服器”更新成“主伺服器”。

  再去redis-slave1所在的指令視窗運作info replication指令，就能看到如下的部分結果，從箭頭所指可看出該Redis伺服器在redis-master1失效後确實已經從屬于172.17.0.7:6384所指向的伺服器。

通過本步驟的輸出結果，能進一步确認“故障自動恢複”動作已經成功完成。

5、通過日志觀察故障恢複流程

  由于在啟動redis-sentinel1和redis-sentinel2節點時制定了日志的路徑和位置，這裡可以在對應的Docker容器裡通過日志觀察具體的故障恢複流程。

  先到redis-sentinel1所在的容器裡用

cat /sentinel1.log

指令觀察該哨兵節點在故障恢複時的動作，就能看到如下内容

  日志中的sdown的含義是“主管下線”，與之對應的是表示客觀下線的odown。當本哨兵節點發現所監控的master伺服器下線後，會先将它标記為“主管下線”，當多個哨兵節點(根據設定，這裡需要2個)都判斷伺服器下線後，如日志中第1處圈起來那塊，随後把該伺服器标記為客觀下線。

  當檢測到客觀下線後，會啟動故障恢複(failover)流程,通過後面的日志，能看出故障恢複的各個步驟，這些細節可以不用關心。完成故障恢複後，會切換主伺服器，切換完成後，會加載從伺服器。至此，完成了故障自動恢複的流程。目前主從模式叢集效果如下圖。

  然後到redis-salve2所在的容器，執行

cat /sentinel2.log

指令檢視該哨兵節點的日志，其中和故障恢複相關的内容如下所示。

  由于隻能由一個哨兵節點完成故障自動恢複的動作，是以如果有多個哨兵節點同時監控到主伺服器失效，那麼最終隻能有一個哨兵節點通過競争得到故障恢複的權力。

  從上文的日志中可以看到，由于故障恢複的權利已經被redis-sentinel1節點競争得到，是以當redis-sentinel2節點發現主伺服器失效後，隻能停留在主管下線(sdown)階段，而無法進行故障恢複動作。隻有當redis-sentinel1節點完成故障恢複動作後，redis-sentienl2節點才能輸出後續的日志，感覺到重構後的主從複制模式叢集，并繼續監控該叢集裡的節點。

6、故障節點恢複後的表現

  從上文日志可以看到，此時雖然redis-master1伺服器依然處于失效狀态，但是在新的主從複制叢集裡依然會把該伺服器當成“從伺服器”。再到redis-master1所在的指令行視窗用

docker start redis-master1

指令啟動容器，以此來模拟該伺服器排除故障後的效果。

運作完指令後，再到redis-salve22所在的指令行視窗裡運作

info replication

指令，就能看到如下的輸出，可以看到故障恢複後的redis-master1伺服器會自動以“從伺服器”的身份接入

  總結，哨兵節點不僅能自動恢複故障，而且當故障節點恢複後會自動把它重新加入到叢集中，而無需人工幹預。也就是說，與簡單的“主從複制模式叢集”相比，基于哨兵模式的叢集能很好地提升系統地可靠性。