一、故障描述

          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/，如需轉載，請註明出處，否則將追究法律責任。