用 docker 學習 redis 主從複製3.2 redis-sentinel「哨兵模式」核心配置-命令-原理

核心配置

sentinel 可監控多個主節點，通過命名來區分，例如master1 master2 ..
```
 sentinel monitor master1 172.10.0.5 2
 sentinel monitor master2 ..
```

哨兵判斷主節點下線的標準

 #Sentinel 會 ping 每個節點，如果超過30秒依然沒有回覆的話，做下線的判斷
 sentinel down-after-milliseconds mymaster 30000

什麼是主觀下線和客觀下線
其中一臺 sentinel 認為主節點下線了，稱為「主觀的」，當 n 臺都認為它下線了，稱為「客觀的」。n 就是第一點配置最後邊的數字 2。當客觀下線時，就開啟故障轉移。
故障轉移之後限制向新節點發起復制的個數
sentinel 領導者做故障轉移工作，它會傳送給每個從節點向新的主節點發起復制的命令，此引數決定這個步驟是併發還是序列。

如果主節點的從節點過多，設定合適的值，可減少主節點的壓力。
```
 #`1`代表每次只能複製一個
 sentinel parallel-syncs mymaster 1
```

配置連線受監控的主節點的密碼

 sentinel auth-pass <master-name> <password>

sentinel 命令

首先連線任一臺 sentinel (不需要進入容器)，22531 是 sentinel1 的外對映埠 22531=>26379

[root@VM-0-8-centos ~]# redis-cli -p 22531
127.0.0.1:22531>

命令列方式新增、刪除監控主節點
在之前配置 sentinel 時是從 /etc/redis-sentinel.conf中修改的，然而還可以通過命令列方式配置
```
 127.0.0.1:22531> sentinel monitor test 127.0.0.1 6666 2
 OK
 127.0.0.1:22531> sentinel remove test
 OK
```

顯示監控的所有 masters 以及它們的狀態

 SENTINEL masters

 127.0.0.1:22531> SENTINEL masters
 1)  1) "name"
     2) "mymaster" #自定義名稱
     3) "ip"
     4) "172.10.0.5"
     5) "port"
     6) "6379"
     ..

顯示指定 master 的資訊和狀態

 SENTINEL master <master name>

 127.0.0.1:22531> SENTINEL master mymaster
  1) "name"
  2) "mymaster"
 3) ...

顯示指定 master 的所有從節點

 SENTINEL slaves <master name>

 127.0.0.1:22531> SENTINEL slaves mymaster
 1)  1) "name"
     2) "172.10.0.2:6379"
     3) "ip"
     4) "172.10.0.2"
     5) "port"
     6) "6379"
     ...
 2)  1) "name"
     2) "172.10.0.4:6379"
     3) "ip"
     4) "172.10.0.4"
     ...

返回指定 master 的 ip 和埠。，如果正在進行 failover 或者failover 已經完成，將會顯示被提升為 master 的 slave 的 ip 和埠。
```
 SENTINEL get-master-addr-by-name <master name>
```
```
 127.0.0.1:22531> SENTINEL get-master-addr-by-name mymaster
 1) "172.10.0.5"
 2) "6379"
```

強制 sentinel 執行 failover，並且不需要得到其他 sentinel 的同意。但是 failover 後會將最新的配置傳送給其他 sentinel。

 SENTINEL failover <master name>

提示：當前的 cli 是sentinel1 節點，那麼就由 sentinel1 節點執行故障轉移。

 127.0.0.1:22531> sentinel failover mymaster
 OK

sentinel1 日誌

 //收到命令
 # Executing user requested FAILOVER of 'mymaster'
 //遞增叢集狀態版本號，這個版本號將被接下來選舉出的新的master採用。
 # +new-epoch 4
 //開始對名為"mymaster"的Redis叢集進行故障轉移
 # +try-failover master mymaster 172.10.0.5 6379
 //投票給自己做領導者
 # +vote-for-leader b0d33c8c68f57a0e3e628bf5cded4419a492177c 4
 //選擇領導者完畢（就是自己）
 # +selected-leader master mymaster 172.10.0.5 6379
 ...

sentinel2 和 sentinel3 日誌

 # +new-epoch 4
 # +config-update-from sentinel b0d33c8c68f57a0e3e628bf5cded4419a492177c 172.10.0.11 26379 @ mymaster 172.10.0.5 6379
 # +switch-master mymaster 172.10.0.5 6379 172.10.0.2 6379
 * +slave slave 172.10.0.4:6379 172.10.0.4 6379 @ mymaster 172.10.0.2 6379
 * +slave slave 172.10.0.5:6379 172.10.0.5 6379 @ mymaster 172.10.0.2 6379
 * +convert-to-slave slave 172.10.0.5:6379 172.10.0.5 6379 @ mymaster 172.10.0.2 6379

可見 sentinel 叢集並沒有投票，sentinel1 直接完成了故障轉移的工作（即使當前主節點是正常狀態），然後將最新的配置傳送給其他sentinel。

總結 sentinel 的原理

Sentinel 的實現原理，主要分為以下三個步驟。

檢測問題，主要講的是三個定時任務，這三個內部的執行任務可以保證出現問題馬上讓 Sentinel 知道。
發現問題，主要講的是主觀下線和客觀下線。當有一臺 Sentinel 機器發現問題時，它就會主觀對它主觀下線，但是當多個 Sentinel 都發現有問題的時候，才會出現客觀下線。
找到解決問題的人，主要講的是領導者選舉，如何在 Sentinel 內部多臺節點做領導者選舉，選出一個領導者。
解決問題，主要講的是故障轉移，即如何進行故障轉移。

Sentinel 內部的三個定時任務。

每10秒每個 Sentinel 對 Master 和 Slave 執行一次 Info Replication。
每2秒每個 Sentinel 通過 Master 節點的 channel 交換資訊（pub/sub）。
每1秒每個 Sentinel 對其他 Sentinel 和 Redis 執行 ping。

第一個定時任務，指的是 Redis Sentinel 可以對 Redis 節點做失敗判斷和故障轉移，在 Redis 內部有三個定時任務作為基礎，來 Info Replication 發現 Slave 節點，這個命令可以確定主從關係。

第二個定時任務，類似於釋出訂閱，Sentinel 會對主從關係進行判定，通過_sentinel_:hello 頻道互動。瞭解主從關係可以幫助更好的自動化操作 Redis。然後 Sentinel 會告知系統訊息給其它 Sentinel 節點，最終達到共識，同時 Sentinel 節點能夠互相感知到對方。

第三個定時任務，指的是對每個節點和其它 Sentinel 進行心跳檢測，它是失敗判定的依據。

sentinel 如何選擇「合適的 Slave」節點

Redis 內部其實是有一個優先順序配置的，在配置檔案中 slave-priority，這個引數是 Salve 節點的優先順序配置，如果存在則返回，如果不存在則繼續。

當上面這個優先順序不滿足的時候，Redis 還會選擇複製偏移量最大的 Slave節點，如果存在則返回，如果不存在則繼續。之所以選擇偏移量最大，這是因為偏移量越小，和 Master 的資料越不接近，現在 Master掛掉了，說明這個偏移量小的機器資料也可能存在問題，這就是為什麼要選偏移量最大的 Slave 的原因。

如果發現偏移量都一樣，這個時候 Redis 會預設選擇 runid 最小的節點。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

focus