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

php_yt發表於2022-01-09
DockerRedis模式
系列文章：
用 docker 學習 redis 主從複製2 主從同步的offset 用 docker 學習 redis 主從複製 用 docker 學習 redis 主從複製3 redis-sentinel「哨兵模式」 用 docker 學習 redis 主從複製3.2 redis-sentinel「哨兵模式」核心配置-命令-原理

核心配置

更多配置在 redisdoc.com/topic/sentinel

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

     sentinel monitor master1 172.10.0.5 2
 sentinel monitor master2 ..

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

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

  3. 什麼是主觀下線和客觀下線
    其中一臺 sentinel 認為主節點下線了，稱為「主觀的」，當 n 臺都認為它下線了，稱為「客觀的」。n 就是第一點配置最後邊的數字 2。當客觀下線時，就開啟故障轉移。

  4. 故障轉移之後限制向新節點發起復制的個數
    sentinel 領導者做故障轉移工作，它會傳送給每個從節點向新的主節點發起復制的命令，此引數決定這個步驟是 併發還是序列。
    故障轉移之後限制向新節點發起復制的個數圖解
    如果主節點的從節點過多，所有從節點都併發進行復制，對主節點會造成壓力。

     #`1`代表每次只能複製一個
 sentinel parallel-syncs mymaster 1

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

     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>

1 顯示監控的所有 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"
    ..

  1. 顯示指定 master 的資訊和狀態

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

  2. 顯示指定 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"
     ...

  3. 返回指定 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"

  4. 強制 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 的實現原理，主要分為以下三個步驟。

  1. 檢測問題，主要講的是三個定時任務，這三個內部的執行任務可以保證出現問題馬上讓 Sentinel 知道。

  2. 發現問題，主要講的是主觀下線和客觀下線。當有一臺 Sentinel 機器發現問題時，它就會主觀對它主觀下線，但是當多個 Sentinel 都發現有問題的時候，才會出現客觀下線。

  3. 找到解決問題的人，主要講的是領導者選舉，如何在 Sentinel 內部多臺節點做領導者選舉，選出一個領導者。

  4. 解決問題，主要講的是故障轉移，即如何進行故障轉移。

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

相關文章