首頁  >  文章  >  資料庫  >  深入搞懂Redis中的哨兵

深入搞懂Redis中的哨兵

青灯夜游
青灯夜游轉載
2023-04-26 17:59:181517瀏覽

Redis哨兵詳解,哨兵搭建流程,哨兵的運作流程和選舉原理(主觀下線,客觀下線,如何選舉出哨兵leader)。

深入搞懂Redis中的哨兵

Redis哨兵(sentinel)

哨兵是什麼?

吹哨人巡查監控後台master主機是否有故障,如果故障了根據投票數自動將某一個從庫轉換為新主庫,繼續對外服務。 【相關推薦:Redis影片教學

俗稱,無人值守運維。

幹什麼?

  • 主從監控:監控主從redis庫執行是否正常
  • 訊息通知:哨兵可以將故障轉移的結果傳送給客戶端
  • 故障轉移:將其中一個Slave作為新的Master
  • 配置中心:客戶端透過連接哨兵來獲得目前Redis服務的主節點位址

案例

架構

3個哨兵:自動監控和維護集群,不存放數據,只是吹哨者。

1主2從:用於讀取與存放資料

深入搞懂Redis中的哨兵

#步驟

  • 將redis安裝路徑下的sentinel.conf 拷貝到myredis目錄下

    cp sentinel.conf /myredis/sentinel26379.conf
  • 修改設定檔

    vim sentinel26379.conf
        
    bind 0.0.0.0
        
    # protected-mode yes 修改为 protected-mode no
    protected-mode no
    
    # daemonize no 修改为 daemonize yes
    daemonize yes
    
    # port 
    port 26379
    
    # pid文件名字,pidfile
    pidfile /var/run/redis_26379.pid
        
    # log文件名字,logfile(修改 logfile "" 为 logfile "/myredis/26379.log")
    logfile "/myredis/26379.log"
    
    # 指定当前的工作目录(修改 dir /temp 为 dir /myredis)
    dir /myredis

    設定要監控的master伺服器

    quorum:確認客觀下線的最少哨兵數。同意故障遷移的法定票數。

    # sentinel monitor <master-name> <ip> <redis-port> <quorum>

    設定連線master服務的密碼

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

    #我們知道,網路是不可靠的,有時候一個sentinel會因為網路阻塞而誤以為一個master redis已經死掉了,在sentinel集群環境下需要多個sentinel互相溝通來確認某個master是否真的死了,quorum這個參數是進行客觀下線的一個依據,意思是至少有quorum個sentinel認為這個master有故障,才會對這個master進行下線以及故障轉移。因為有的時候,某個sentinel節點可能因為自身網路原因,導致無法連接master,而此時master並沒有出現故障,所以,這就需要多個sentinel都一致認為該master有問題,才可以進行下一步操作,這保證了公平性和高可用。

安裝三台linux

ip和port分別為

# sentinel00
192.168.157.112    26379
# sentinel01
192.168.157.113    26380
# sentinel02
192.168.157.118    26381

設定三台哨兵

sentinelxxxx.conf檔案

sentinel00

sentinel26379.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel01

sentinel26380.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel02

sentinel26381. conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

測試

  • 基於先前的redis複製,啟動1主2從測試是否主從複製是否正常,輸入info replication 檢視是否正常

  • #啟動三台哨兵,完成監控

    redis-sentinel /myredis/sentinel26379.conf --sentinel
    redis-sentinel /myredis/sentinel26380.conf --sentinel
    redis-sentinel /myredis/sentinel26381.conf --sentinel
  • 測試主從複製,一切良好

  • ##查看日誌

深入搞懂Redis中的哨兵

  • 檢視設定檔sentinel.conf

深入搞懂Redis中的哨兵

> 后面为自动新增内容

-

模擬master宕機

  • master主機

    # 模拟宕机
    shudown

    ##問題

    兩台從機資料是否正常? (yes)
    1. 會不會從剩下的兩台機器中選出新的master?(yes)
    2. 之前的master重啟之後會不會重新上位,重新成為master? (no)
  • salve取得資料

深入搞懂Redis中的哨兵

    查看新的master

深入搞懂Redis中的哨兵

    重寫啟動原始master
  • #master不會重新上位。

深入搞懂Redis中的哨兵對比設定檔

#檔案的內容,在執行期間會被sentinel動態修改。 master—slave主從關係切換後,設定檔內容會自動改變。

    sentinel6379.conf 檔案

深入搞懂Redis中的哨兵

    舊master

深入搞懂Redis中的哨兵

  • 新master

深入搞懂Redis中的哨兵

深入搞懂Redis中的哨兵

哨兵运行流程和选举原理

当一个主从配置中的master失效后,sentinel可以选举出一个新的master用于自动替换原master的工作,主从配置中的其他redis服务自动指向新的master同步数据,一般建议sentinel采取奇数台,防止某一台sentinel无法连接到master导致误切换。

SDown主观下线(Subjectively Down)

SDOWN(主观不可用)是单个哨兵自己主观检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就到达了SDOQN的条件。

sentinel配置文件中的 down-after-milliseconds 设置了主观下线的时间长度(默认30秒)。

# sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能确认一个master客观上已经宕机了。

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

选举出领导者哨兵

当主节点被判断客观下线后,各个哨兵节点会进行协商,先选举出一个领导者哨兵节点,并由该领导者哨兵节点进行failover(故障迁移)

领导者哨兵如何选出来的?

Raft算法

监视该主节点的所有哨兵都有可能被选为领导者,选举使用的算法是Raft算法;Raft算法的基本思路是先到先得,即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者。

深入搞懂Redis中的哨兵

选新的master(im)

整个过程由sentinel自己独立完成,无需人工干涉。

新主登基

某一个slave被选中成为master

选出新的master的规则,剩余slave节点健康的前提下

  1. redis.conf文件中,优先级slave-priority或者replica-priority最高节点(数字越小优先级越高)
  2. 复制偏移量offset最大的从节点。
  3. 最小Run ID的从节点。

深入搞懂Redis中的哨兵

群臣俯首

  • 执行 slaveof no one 命令让选出来的从节点成为新的主节点,并通过 slaveof 命令让其他节点成为其从节点。

  • sentinel leader 会对选举出来的新 master 执行 slaveof no one,将其提升为master节点

  • sentinel leader 向其他slave发送命令,让剩余的slave成为新的master节点的slave。

旧主拜服

  • 将之前的已经下线的旧master设置为新选出的新master的从节点,当旧master重新上线后,它会成为新master的从节点
  • sentinel leader 会让原来的master降级为slave并恢复正常工作。

哨兵使用建议

  • 哨兵节点数量应该为多个,哨兵本身应该为集群,保证高可用
  • 哨兵节点数量应该是奇数
  • 各个哨兵节点的配置应该一致
  • 如果哨兵节点部署在docker等容器里面,尤其要注意端口的正确映射
  • 哨兵集群 + 主从复制,并不能保证数据零丢失

更多编程相关知识,请访问:编程视频!!

以上是深入搞懂Redis中的哨兵的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文轉載於:juejin.cn。如有侵權,請聯絡admin@php.cn刪除