redis經典模式3節點哨兵配置的一些坑

e71hao發表於2020-07-24

一、故障描述

          redis版本:redis_version:4.0.10

        操心繫統:centos7.5

        redis拓撲結構:三個主機,每個主機一個redis和sentinel.redis是主從模式。

          故障描述:假如redis主節點當機,剩餘2個從節點不能正常進行故障轉移。

           哨兵日誌錯誤:failover-abort-slave-timeout  ,failover-abort-no-good-slave

二、 結論

            (1) redis_version:4.0.10 版本,使用了rename命令進行了更改config命令, 假如其中主機節點當機,會發生 failover-abort-slave-timeout錯誤,sentinel不能成功進行故障轉移。

        (2) 3節點哨兵模式下,sentinel 配置為 sentinel monitor <master-name> <ip> <port> <quorum> ,其中quorum配置為1,假如其中主機節點當機,會發生腦裂,sentinel不能進行成功選主。

三、模擬故障1

      本機三個主機節點192.168.1.134,192.168.3.141,192.168.3.142,每個節點一個哨兵,一個redis, redis配置加上下面命令:

# security
rename-command BGREWRITEAOF "CHAOSBGREWRITEAOF"
rename-command BGSAVE "CHAOSBGSAVE"
rename-command CONFIG "CHAOSCONFIG"

    

     模擬故障主節點當機,剩餘2個sentinel應該要進行故障轉移,把剩餘的其中一個redis節點提升為主節點。

 拿下sentinel日誌來檢視下

可以看到sentinel已經發現主機節點192.168.3.134已經當機不可達,已經進行選主,然後進行切換,最終切換不成功。 +failover-state-sen-slaveof-noone”: Leader向slave傳送“slaveof no one”指令,此時slave已經完成角色轉換,此slave即為master,看關鍵字failover-abort-slave-timeout. 原因已經查詢出來:為了安全的原因,改寫了命令,本來redis的命令是CONFIG,被改為CHAOSCONFIG。

# security
#rename-command BGREWRITEAOF "CHAOSBGREWRITEAOF"
#rename-command BGSAVE "CHAOSBGSAVE"
#rename-command CONFIG "CHAOSCONFIG"

    把這個命令登出掉就不會發生 failover-abort-slave-timeout錯誤了。


四、模擬故障2

      本機三個主機節點192.168.1.134,192.168.3.141,192.168.3.142,每個節點一個哨兵,一個redis。注意一下哨兵配置如下:

[root@elk1 ~]# cat /opt/redis_lifekh/sentinel/sentinel.conf 
bind 192.168.3.134
protected-mode yes
port 7111
dir "/opt/redis_lifekh/sentinel"
daemonize yes
logfile "/log/redis_lifekh/6379/sentinel-7111.log"
sentinel myid fe521155a801ac9199f3a8e9d27301edc7d2aab8
sentinel monitor mymaster 192.168.3.142 6379 1

     注意配置1  sentinel monitor <master-name> <ip> <port> <quorum>, <quorum> 代表要判定主節點最終不可達所需要的票數。也就是說只有1票,sentinel發現redis沒有心跳,就會從主觀下線sdown變成客觀下線odown,接著sentinel就可以進行sentinel的選主。

sentinel monitor mymaster 192.168.3.142 6379 1

    

redis配置如下

[root@elk1 ~]# cat /opt/redis_lifekh/sentinel/redis.conf 
bind 192.168.3.134
protected-mode yes
port 6379
tcp-backlog 511
timeout 60
tcp-keepalive 300
daemonize yes
supervised no
pidfile "/data/redis_lifekh/6379/redis-6379.pid"
loglevel notice
logfile "/log/redis_lifekh/6379/redis-6379.log"
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
slaveof  192.168.3.134

   把環境搭建好模擬主節點當機,看到並沒有進行正常故障轉移,日誌如下:

看關鍵日誌failover-abort-no-good-slave

五、總結

        以上2個故障可以重現。注意的哨兵的 quorum配置不正確,會導致腦裂發生,導致不能正常進行選主。3 個sentinel,quorum配置為2,5個sentinel, quorum配置為3。


參考: https://www.cnblogs.com/myd620/p/7811156.html 

Raft協議實戰之Redis Sentinel的選舉Leader原始碼解析


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30393770/viewspace-2706857/,如需轉載,請註明出處,否則將追究法律責任。

相關文章