Redis高可用之哨兵(sentinel)實際部署和分析篇

2020-08-29 小兵挖DB

我們以一主兩從的複製方式結合案例學習一下哨兵的部署,相關環境如下

redis+sentinel

redis複製部署

redis複製部署請參考另外一篇文章

部署完成後效果如下

  • 主節點ec2-redis-01

> info replication34;master&34;192.168.100.4&34;6379&34;368018&34;192.168.100.3&34;6379&34;368032& Replicationrole:slavemaster_host:192.168.100.2master_port:6379master_link_status:upmaster_last_io_seconds_ago:0master_sync_in_progress:0slave_repl_offset:368298slave_priority:100slave_read_only:1connected_slaves:0master_replid:4668490d0bd8e3d2967fe33eb49efde8af6a537bmaster_replid2:0000000000000000000000000000000000000000master_repl_offset:368298second_repl_offset:-1repl_backlog_active:1repl_backlog_size:10485760repl_backlog_first_byte_offset:43repl_backlog_histlen:368256127.0.0.1:6379> role1) &34;2) &34;3) (integer) 63794) &34;5) (integer) 368312

  • 從節點ec2-redis-03

> info replication34;slave&34;192.168.100.2&34;connected&34;/var/run/redis-sentinel.pid&34;/usr/local/redis/log/sentinel.log&34;/usr/local/redis/data& cat /usr/lib/systemd/system/sentinel.service [Unit]Description=Redis Sentinel provides high availability for Redis.Documentation=https://redis.io/topics/sentinelAfter=syslog.targetAfter=network.targetAfter=redis.target //注意sentinel服務最好在redis服務啟動後再啟動.[Service]Type=notifyUser=redisGroup=dbaRestart=always systemctl daemon-reload systemctl start sentinel oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo17397:X 04 Jul 2020 21:02:31.744 Configuration loaded17397:X 04 Jul 2020 21:02:31.744 * supervised by systemd, will signal readiness17397:X 04 Jul 2020 21:02:31.746 * Running mode=sentinel, port=26379.17397:X 04 Jul 2020 21:02:31.752 +monitor master userservice 192.168.100.2 6379 quorum 217397:X 04 Jul 2020 21:02:31.758 * +slave slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:02:31.761 * +slave slave 192.168.100.3:6379 192.168.100.3 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:02:33.786 * +sentinel sentinel 620c49f4f658095dae056e670822b634a257cc23 192.168.100.4 26379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:02:33.810 * +sentinel sentinel d7ec4699a9744e8b806efba64a12adf74fdf367f 192.168.100.3 26379 @ userservice 192.168.100.2 6379

從每個sentinel哨兵節點的日誌可以看到,哨兵根據我們指定的主節點地址通過info命令找到了所有從節點信息,通過發布和訂閱redis頻道__sentinel__:hello頻道找到了其他哨兵節點

  • sentinel主配置文件更新

哨兵啟動後,在每個哨兵的主配置文件中自動添加了以下動態參數

34;psubscribe&34;__sentinel__:hello&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.4,26379,620c49f4f658095dae056e670822b634a257cc23,0,userservice,192.168.100.2,6379,0&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.2,26379,85519e3d32442ac8c87329f381079007a08f9b9f,0,userservice,192.168.100.2,6379,0&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.3,26379,d7ec4699a9744e8b806efba64a12adf74fdf367f,0,userservice,192.168.100.2,6379,0&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.4,26379,620c49f4f658095dae056e670822b634a257cc23,0,userservice,192.168.100.2,6379,0&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.2,26379,85519e3d32442ac8c87329f381079007a08f9b9f,0,userservice,192.168.100.2,6379,0&34;pmessage&34;__sentinel__:hello&34;__sentinel__:hello&34;192.168.100.3,26379,d7ec4699a9744e8b806efba64a12adf74fdf367f,0,userservice,192.168.100.2,6379,0&34;name&34;userservice&34;ip&34;192.168.100.2&34;port&34;6379&34;runid&34;ce24ee8b27e42b9762ec595deb7542abf9ac4adc&34;flags&34;master&34;link-pending-commands&34;0&34;link-refcount&34;1&34;last-ping-sent&34;0&34;last-ok-ping-reply&34;688&34;last-ping-reply&34;688&34;down-after-milliseconds&34;5000&34;info-refresh&34;9582&34;role-reported&34;master&34;role-reported-time&34;892700&34;config-epoch&34;0&34;num-slaves&34;2&34;num-other-sentinels&34;2&34;quorum&34;2&34;failover-timeout&34;30000&34;parallel-syncs&34;1&34;192.168.100.2&34;6379& systemctl stop redis

分別查看三個節點的log輸出

ec2-redis-01哨兵日誌

17397:X 04 Jul 2020 21:33:40.687 +odown master userservice 192.168.100.2 6379 +new-epoch 117397:X 04 Jul 2020 21:33:40.740 +vote-for-leader 85519e3d32442ac8c87329f381079007a08f9b9f 117397:X 04 Jul 2020 21:33:40.745 620c49f4f658095dae056e670822b634a257cc23 voted for 85519e3d32442ac8c87329f381079007a08f9b9f 117397:X 04 Jul 2020 21:33:40.813 +failover-state-select-slave master userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:40.866 +promoted-slave slave 192.168.100.3:6379 192.168.100.3 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:41.467 -odown master userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:42.478 * +slave-reconf-inprog slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:42.478 * +slave-reconf-done slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:42.544 +switch-master userservice 192.168.100.2 6379 192.168.100.3 637917397:X 04 Jul 2020 21:33:42.545 * +slave slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.3 637917397:X 04 Jul 2020 21:33:42.545 * +slave slave 192.168.100.2:6379 192.168.100.2 6379 @ userservice 192.168.100.3 637917397:X 04 Jul 2020 21:33:47.548 User requested shutdown...1447:M 04 Jul 2020 21:33:35.576 * Calling fsync() on the AOF file.1447:M 04 Jul 2020 21:33:35.576 * Saving the final RDB snapshot before exiting.1447:M 04 Jul 2020 21:33:35.607 * DB saved on disk1447:M 04 Jul 2020 21:33:35.607 * Removing the pid file.1447:M 04 Jul 2020 21:33:35.607 +sdown master userservice 192.168.100.2 637916627:X 04 Jul 2020 21:33:45.469 quorum 2/216627:X 04 Jul 2020 21:33:45.469 +try-failover master userservice 192.168.100.2 637916627:X 04 Jul 2020 21:33:45.472 85519e3d32442ac8c87329f381079007a08f9b9f voted for 85519e3d32442ac8c87329f381079007a08f9b9f 116627:X 04 Jul 2020 21:33:45.485 +config-update-from sentinel 85519e3d32442ac8c87329f381079007a08f9b9f 192.168.100.2 26379 @ userservice 192.168.100.2 637916627:X 04 Jul 2020 21:33:46.264 +sdown slave 192.168.100.2:6379 192.168.100.2 6379 @ userservice 192.168.100.3 6379

ec2-redis-02 redis日誌

1448:S 04 Jul 2020 21:33:40.336 Error condition on socket for SYNC: Connection refused1448:S 04 Jul 2020 21:33:42.015 * Connecting to MASTER 192.168.100.2:63791448:S 04 Jul 2020 21:33:42.015 * MASTER <-> REPLICA sync started1448:S 04 Jul 2020 21:33:42.015 Error condition on socket for SYNC: Connection refused1448:S 04 Jul 2020 21:33:44.030 * Connecting to MASTER 192.168.100.2:63791448:S 04 Jul 2020 21:33:44.030 * MASTER <-> REPLICA sync started1448:S 04 Jul 2020 21:33:44.030 Error condition on socket for SYNC: Connection refused1448:M 04 Jul 2020 21:33:45.677 39;id=43 addr=192.168.100.2:27104 fd=10 name=sentinel-85519e3d-cmd age=1869 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qb1448:M 04 Jul 2020 21:33:45.678 +sdown master userservice 192.168.100.2 637916556:X 04 Jul 2020 21:33:45.473 +vote-for-leader 85519e3d32442ac8c87329f381079007a08f9b9f 116556:X 04 Jul 2020 21:33:46.263 +switch-master userservice 192.168.100.2 6379 192.168.100.3 637916556:X 04 Jul 2020 21:33:46.264 * +slave slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.3 637916556:X 04 Jul 2020 21:33:46.264 * +slave slave 192.168.100.2:6379 192.168.100.2 6379 @ userservice 192.168.100.3 637916556:X 04 Jul 2020 21:33:51.296 Connection with master lost.1444:S 04 Jul 2020 21:33:40.336 * Caching the disconnected master state.1444:S 04 Jul 2020 21:33:40.900 * Connecting to MASTER 192.168.100.2:63791444:S 04 Jul 2020 21:33:40.900 * MASTER <-> REPLICA sync started1444:S 04 Jul 2020 21:33:40.905 Error condition on socket for SYNC: Connection refused1444:S 04 Jul 2020 21:33:42.919 * Connecting to MASTER 192.168.100.2:63791444:S 04 Jul 2020 21:33:42.919 * MASTER <-> REPLICA sync started1444:S 04 Jul 2020 21:33:42.920 Error condition on socket for SYNC: Connection refused1444:S 04 Jul 2020 21:33:44.937 * Connecting to MASTER 192.168.100.2:63791444:S 04 Jul 2020 21:33:44.938 * MASTER <-> REPLICA sync started1444:S 04 Jul 2020 21:33:44.938 Error condition on socket for SYNC: Connection refused1444:S 04 Jul 2020 21:33:46.263 * REPLICAOF 192.168.100.3:6379 enabled (user request from &39;)1444:S 04 Jul 2020 21:33:46.264 Master replication ID changed to 727e32660ce348fc07a7805b06954ef9752821b71444:S 04 Jul 2020 21:33:46.961 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.

首先,在哨兵節點監測到主節點宕機後,認為該主節點進入主觀下線狀態(sdown),通過三個哨兵節點的的輸出日誌可以看出,如下

17397:X 04 Jul 2020 21:33:40.687 +odown master userservice 192.168.100.2 6379 +odown master userservice 192.168.100.2 6379 +try-failover master userservice 192.168.100.2 6379

哨兵ec2-redis-02

16627:X 04 Jul 2020 21:33:45.469 +vote-for-leader 85519e3d32442ac8c87329f381079007a08f9b9f 1

哨兵ec2-redis-02投票

16627:X 04 Jul 2020 21:33:45.472 +vote-for-leader 85519e3d32442ac8c87329f381079007a08f9b9f 1

以上可以看到,運行id為85519e3d32442ac8c87329f381079007a08f9b9f的哨兵節點共獲得2票,成為領頭哨兵,而且哨兵ec2-redis-01的日誌裡也顯示自己獲得了多數票數成為領頭哨兵

17397:X 04 Jul 2020 21:33:40.813 +selected-slave slave 192.168.100.3:6379 192.168.100.3 6379 @ userservice 192.168.100.2 6379

然後領頭哨兵開始執行故障轉移

17397:X 04 Jul 2020 21:33:40.866 * +failover-state-send-slaveof-noone slave 192.168.100.3:6379 192.168.100.3 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:40.950 * +failover-state-wait-promotion slave 192.168.100.3:6379 192.168.100.3 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:41.467 +failover-state-reconf-slaves master userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:41.536 * +slave-reconf-sent slave 192.168.100.4:6379 192.168.100.4 6379 @ userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:41.839 +failover-end master userservice 192.168.100.2 637917397:X 04 Jul 2020 21:33:42.544 +sdown slave 192.168.100.2:6379 192.168.100.2 6379 @ userservice 192.168.100.3 6379

哨兵ec2-redis-02的日誌和哨兵ec2-redis-02的日誌說明領頭哨兵讓其他哨兵節點以自己的信息為準強制其他哨兵節點更新配置信息,如下所示.

16627:X 04 Jul 2020 21:33:46.263 CONFIG REWRITE executed with success.

這裡需要說明的是,連接原來主節點的從節點重新連接新的主節點後,並不需要從新的主節點同步一份完整的數據,僅僅需要同步缺失的數據即可.

1444:S 04 Jul 2020 21:33:46.957 * Connecting to MASTER 192.168.100.3:63791444:S 04 Jul 2020 21:33:46.957 * MASTER <-> REPLICA sync started1444:S 04 Jul 2020 21:33:46.957 * Non blocking connect for SYNC fired the event.1444:S 04 Jul 2020 21:33:46.958 * Master replied to PING, replication can continue...1444:S 04 Jul 2020 21:33:46.960 * Trying a partial resynchronization (request 4668490d0bd8e3d2967fe33eb49efde8af6a537b:1603594).1444:S 04 Jul 2020 21:33:46.961 * Successful partial resynchronization with master.1444:S 04 Jul 2020 21:33:46.961 systemctl start redis

首先哨兵節點會將該節點降級為新的主節點的從節點

17397:X 04 Jul 2020 22:53:18.228 39;839c9173e6e76ea20ebf46f36c963bc9f81ac84c&39;727e32660ce348fc07a7805b06954ef9752821b7&39;4668490d0bd8e3d2967fe33eb49efde8af6a537b& Next failover delay: I will not start a failover before Sun Jul 5 11:35:13 2020

以上簡單對哨兵的實際部署和故障轉移過程做一個簡單的介紹.

相關焦點

  • Redis高可用之哨兵(sentinel)技術原理
    哨兵的版本選擇和運行哨兵的版本哨兵的版本分為版本1和版本2,版本1在redis2.6正式發布,但是是不穩定版本,已經遺棄,從redis2.8開始,哨兵版本2正式推出.redis-sentinel /path/to/sentinel.confredis-server /path/to/sentinel.conf --sentinel在部署哨兵前,我們需要知道下列基礎知識部署哨兵至少需要三個不同的節點,且該三個節點最好相互獨立,即不在同一個交換機或機櫃.
  • Redis哨兵模式搭建及高可用測試
    在工作當中，測試環境或者個人使用 redis 時，由於項目實施時間、部署複雜度、伺服器資源等因素限制，很多時候均為單機部署，但在生產環境，為保證業務連續性，一般是不允許單機部署方式，而是採用集群或哨兵模式。
  • Redis高可用之哨兵(sentinel)客戶端(Python)連接
    ()))在引入哨兵功能後,我們需要使用redis模塊的子模塊sentinel,例如我們查看當前主節點和從節點信息from redis import sentinelsentinel_connection = sentinel.Sentinel([(&39;, 26379), (&39;, 26379), (&39;, 26379)], db
  • Redis系列：高可用哨兵方案部署
    監控（Monitoring）：Sentinel 會不斷地檢查主伺服器和從伺服器是否運作正常。如果大家有多臺虛擬主機的話，也可以使用多臺虛擬主機部署。/redis/redis-26379.confcp /usr/local/redis/etc/redis.conf /usr/local/redis/redis-26380.conf基於sentinel.conf 創建哨兵配置文件，sentinel.conf配置文件可以在下載的redis源碼目錄找到
  • Redis高可用sentinel 來龍去脈
    redis sentinel 是從redis 2.8開始提供的一個redis 高可用的功能,此篇的前置原理為,需要能安裝REDIS 伺服器,並且配置主從關係, Redis 有兩種高可用, redis cluster 和 redis sentinel , 今天主要說 sentinel。
  • Redis哨兵機制Sentinel在windows下的部署
    2.分別修改redis.windows.conf、redis.windows-service.conf配置。（具體配置略）3.我採用一主(Master)二從(slave)三哨兵sentinel的架構模式來做演示。
  • Redis哨兵(Sentinel)模式，帶你快速入門
    1.部署主從節點哨兵系統中的主從節點，與普通的主從節點配置是一樣的，並不需要做任何額外配置。下面分別是主節點（port=8000）和2個從節點（port=8001/8002）的配置文件；我們剛才搭建的主從複製就是主從節點2.部署哨兵節點哨兵節點本質上是特殊的Redis節點。
  • Redis哨兵（Sentinel）模式
    這裡的哨兵有兩個作用通過發送命令，讓Redis伺服器返回監控其運行狀態，包括主伺服器和從伺服器。切換成功後，就會通過發布訂閱模式，讓各個哨兵把自己監控的從伺服器實現切換主機，這個過程稱為客觀下線。這樣對於客戶端而言，一切都是透明的。二、Redis配置哨兵模式配置3個哨兵和1主2從的Redis伺服器來演示這個過程。
  • 一文帶你了解Redis哨兵模式和高可用集群解析
    1.redis cluster集群是什麼？redis cluster集群是一個由多個主從節點群組成的分布式伺服器群，它具有複製、高可用和分片特 性。Rediscluster集群不需要sentinel哨兵也能完成節點移除和故障轉移的功能。
  • Redis高可用之哨兵(sentinel)在客戶端一側的實現
    redis哨兵是對主從複製技術的補充,負責監控redis主從複製並在主節點宕機後執行自動故障轉移,同時更新故障轉移後新的配置,並提供客戶端最新的主節點和從節點信息.客戶端也被明確要求支持redis哨兵功能redis客戶端通過哨兵發現redis服務redis哨兵通過一個別名來唯一標註一個主從複製架構中的主節點信息
  • Redis哨兵(Sentinel)模式如何做到高可用的?
    原來的主伺服器被降級為從伺服器看完上面的四張圖，相信大家對Sentinel的整體部署已經有了個了解。接下來讓我們進一步了解...2 Sentinel的初始化過程啟動一個Sentinel可以使用命令：$ redis-sentinel sentinel.conf或者$ redis-server sentinel.conf --sentinel這兩個命令的效果完全相同。
  • 為什麼需要 Redis 哨兵?
    什麼是哨兵？Redis Sentinel 是一個分布式的架構，它本身也是一個獨立的 Redis 節點，只不過它不存儲數據，只支持部分命令，它能夠自動完成故障發現和故障轉移，並通知應用方，從而實現高可用。
  • 你真的懂Redis哨兵技術嗎？
    它們包括：持久化、複製、哨兵和集群，其主要作用和解決的問題是：持久化：持久化是最簡單的高可用方法（有時甚至不被歸為高可用的手段），主要作用是數據備份，即將數據存儲在硬碟，保證數據不會因進程退出而丟失。哨兵節點的啟動有兩種方式，二者作用是完全相同的：redis-sentinel sentinel-26379.confredis-server sentinel
  • Sentinel（哨兵）是Redis 的高可用性解決方案
    1、Sentinel 哨兵Sentinel（哨兵）是Redis 的高可用性解決方案：由一個或多個Sentinel 實例組成的Sentinel 系統可以監視任意多個主伺服器，以及這些主伺服器屬下的所有從伺服器，並在被監視的主伺服器進入下線狀態時，自動將下線主伺服器屬下的某個從伺服器升級為新的主伺服器。
  • redis sentinel 學習
    主從複製問題手動故障轉移 要手動選出一個新的master(不合理),寫一個自動的腳本又非常複雜寫能力和存儲能力受限redis sentinel架構redis sentinel故障轉移多個sentinel發現並確認master有問題選舉出一個sentinel
  • Redis哨兵模式，面試你被問了嗎
    前言最近面試被問到了，哨兵模式，一聽名詞感覺很陌生，搜索下記憶，還好了解過Redis集群的知識，沒被難倒。哨兵模式是實現Redis集群的一種方案。Redis的集群方案大致有三種：redis cluster集群方案；master/slave主從方案；哨兵模式來進行主從替換以及故障恢復。
  • ...當將軍的「Sentinel」不是好「Sentinel」」之Redis Sentinel架構
    Sentinel (哨兵)是 Redis的高可用性解決方案：由一個或多個 Sentinel實例組成的 Sentinel系統可以監控任意數量的主伺服器和所有這些主伺服器屬下的從伺服器，當被監控的主伺服器進入下線狀態時，會自動將下線主伺服器屬下的一個從伺服器升級到新的主伺服器。
  • 「不想當將軍的「Sentinel」不是好「Sentinel」」之Redis...
    Sentinel (哨兵)是 Redis的高可用性解決方案：由一個或多個 Sentinel實例組成的 Sentinel系統可以監控任意數量的主伺服器和所有這些主伺服器屬下的從伺服器，當被監控的主伺服器進入下線狀態時，會自動將下線主伺服器屬下的一個從伺服器升級到新的主伺服器。
  • Redis精華所在，一口氣說完Redis的主從複製和哨兵模式
    那麼為了解決這個當主機掛了，需要手動重新設置一個主節點的問題，就需要使用我們的哨兵模式。什麼是哨兵顧名思義，哨兵就是用來巡邏檢查的，哨兵每隔一段時間會向redis發送命令，等待redis響應，如果得不到響應，此時這個哨兵會認為這臺redis服務以掛掉。一般情況會啟動多個哨兵，判斷redis主機是否掛掉，哨兵會進行投票。
  • Redis哨兵
    但是通常情況下，我們很難人為的做到在服務宕機時立刻切換主節點，哨兵就是用來替代人為操作的，它作為一個單獨的服務存在，對所有的主從節點進行監控，在主節點發生故障時，立刻在其他的從幾點中，重新選舉出一個節點作為主節點，來保證服務的可用。