Redis Sentinel master 沒有立即降級為 slave

Question

我的架構包含三個 Redis 實例（一個主實例和兩個從實例）和三個 Sentinel 實例。 在它的前面有一個 HaProxy。 一切正常，直到主 Redis 實例出現故障。 新的 master 由 Sentinel 正確選擇。 但是，舊的 master（現已關閉）並未重新配置為 slave。 結果，當那個實例再次啟動時，我在短時間內（大約 11 秒）有兩個主人。 在那之后，被提出的那個實例被適當地降級為奴隸。

它不應該那樣工作嗎，當 master 宕機時，它會立即降級為 slave 嗎？ 這樣一來，再起來的時候，馬上就是slave了。 我知道（自 Redis 2.8 起？）有 CONFIG REWRITE 功能，因此當 Redis 實例關閉時無法修改配置。

在一段時間內擁有兩個主服務器對我來說是個問題，因為 HaProxy 在這么短的時間內沒有向一個主服務器 Redis 發送請求，而是在這兩個主服務器之間進行負載平衡。

有什么辦法可以立即將失敗的master降級為slave嗎？

顯然，我更改了 Sentinel 超時。

以下是 master 宕機后來自 Sentinel 和 Redis 實例的一些日志：

哨兵

81358:X 23 Jan 22:12:03.088 # +sdown master redis-ha 127.0.0.1                       63797.0.0.1 26381 @ redis-ha 127.0.0.1 6379
81358:X 23 Jan 22:12:03.149 # +new-epoch 1
81358:X 23 Jan 22:12:03.149 # +vote-for-leader 6b5b5882443a1d738ab6849ecf4bc6b9b32ec142 1
81358:X 23 Jan 22:12:03.174 # +odown master redis-ha 127.0.0.1 6379 #quorum 3/2
81358:X 23 Jan 22:12:03.174 # Next failover delay: I will not start a failover before Sat Jan 23 22:12:09 2016
81358:X 23 Jan 22:12:04.265 # +config-update-from sentinel 127.0.0.1:26381 127.0.0.1 26381 @ redis-ha 127.0.0.1 6379
81358:X 23 Jan 22:12:04.265 # +switch-master redis-ha 127.0.0.1 6379 127.0.0.1 6381
81358:X 23 Jan 22:12:04.266 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redis-ha 127.0.0.1 6381
81358:X 23 Jan 22:12:04.266 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redis-ha 127.0.0.1 6381
81358:X 23 Jan 22:12:06.297 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ redis-ha 127.0.0.1 6381

Redis

81354:S 23 Jan 22:12:03.341 * MASTER <-> SLAVE sync started
81354:S 23 Jan 22:12:03.341 # Error condition on socket for SYNC: Connection refused
81354:S 23 Jan 22:12:04.265 * Discarding previously cached master state.
81354:S 23 Jan 22:12:04.265 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=7 addr=127.0.0.1:57784 fd=10 name=sentinel-6b5b5882-cmd age=425 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=14 qbuf-free=32754 obl=36 oll=0 omem=0 events=rw cmd=exec')
81354:S 23 Jan 22:12:04.265 # CONFIG REWRITE executed with success.
81354:S 23 Jan 22:12:04.371 * Connecting to MASTER 127.0.0.1:6381
81354:S 23 Jan 22:12:04.371 * MASTER <-> SLAVE sync started
81354:S 23 Jan 22:12:04.371 * Non blocking connect for SYNC fired the event.
81354:S 23 Jan 22:12:04.371 * Master replied to PING, replication can continue...
81354:S 23 Jan 22:12:04.371 * Partial resynchronization not possible (no cached master)
81354:S 23 Jan 22:12:04.372 * Full resync from master: 07b3c8f64bbb9076d7e97799a53b8b290ecf470b:1
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: receiving 860 bytes from master
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Flushing old data
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Loading DB in memory
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Finished with success

Answer 1

當我想使用哨兵在 redis-cluster 中切換 master 時，我也遇到了同樣的錯誤。

+投票給領導者 xxxxxxxxxxxxxxxxxxxxxxxxxxx8989 10495
下一次故障轉移延遲：我不會在 2019 年 8 月 2 日星期五 23:23:44 之前開始故障轉移

重置哨兵后。 集群按預期工作

SENTINEL RESET *

要么

哨兵重置 mymaster

在所有哨兵服務器中運行以上命令。

Answer 2

如果 Redis 節點宕機，當/如果它恢復，它將以與宕機前相同的role恢復。 如果無法 ping 通，則 Sentinel 無法重新配置節點。 因此，在節點恢復和 Sentinel 確認並重新配置它之間有一段短暫的時間。 這解釋了多主機狀態。

如果您准備使用 Haproxy，一種解決方法是在開始該過程之前重新配置 Redis 節點的角色。 只要 redis.conf 中有 SLAVEOF 條目，Redis 就會作為從服務器啟動。 此變通方法的主要問題是它不能解決網絡分區方案。

希望有幫助。

Answer 3

如果使用HAProxy您可以嘗試像這樣查詢uptime_in_seconds ：

backend redis
    mode tcp
    balance first
    timeout queue 5s
    default-server check inter 1s fall 2 rise 2 maxconn 100
    option tcp-check
    tcp-check connect
    tcp-check send AUTH\ <secret>\r\n
    tcp-check expect string +OK
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    tcp-check send info\ replication\r\n
    tcp-check expect string role:master
    tcp-check send info\ server\r\n
    tcp-check expect rstring uptime_in_seconds:\d{2,}
    tcp-check send QUIT\r\n
    tcp-check expect string +OK
    server redis-1 10.0.0.10:9736
    server redis-2 10.0.0.20:9736
    server redis-3 10.0.0.30:9736

請注意：

  tcp-check expect rstring uptime_in_seconds:\d{2,}

如果正常運行時間不大於 10 秒，則不會添加節點

Answer 4

解決方案

這可以通過在 HAProxy 配置中使用rise 選項來解決。

default-server check inter 1s fall 2 rise 30

# OR

server redis-1 127.0.0.1:6379 check inter 1s fall 2 rise 30

這設置了服務器必須通過的成功檢查次數才能被視為 UP。 因此，這可以成功地延遲重新加入的 Redis 節點被視為 UP 並為 Sentinel 提供更改節點角色的機會。

重要的權衡

這種方法的權衡是，您的故障轉移將需要更長的時間才能得到 HAProxy 的尊重，因為您會增加額外的延遲。 這種延遲既適用於失敗后重新加入的節點，也適用於升級為role:master的現有從屬節點。 最終，您需要在哪個選項更適合您之間做出決定； 暫時擁有 2 個主節點，或者需要更長的時間才能在節點之間發生故障。

Answer 5

如果使用haproxy ，一個更穩定的解決方案是檢查可用的從站。 重新啟動、重新啟動或強制切換后，舊的主服務器仍將具有角色主服務器，但沒有連接任何從服務器。 所以價值為零。

# faulty old master
role:master
connected_slaves:0
slave0:ip=127.0.0.2,port=6379,state=online,offset=507346829,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=507346966,lag=0
master_failover_state:no-failover
...

我會更換

    tcp-check expect string role:master
    tcp-check send info\ server\r\n
    tcp-check expect rstring uptime_in_seconds:\d{2,}

和

tcp-check expect rstring connected_slaves:[^0]

我的總配置。

listen listen-REDIS
        bind 1.1.1.1:6379
        mode tcp
        no option prefer-last-server
        option tcplog
        balance leastconn
        option tcp-check
        tcp-check send "auth STRING\r\n"
        tcp-check send PING\r\n
        tcp-check expect string +PONG
        tcp-check send info\ replication\r\n
        tcp-check expect rstring connected_slaves:[^0]
        tcp-check send QUIT\r\n
        tcp-check expect string +OK
        default-server inter 500ms fall 1 rise 1
        server REDIS01 127.0.0.1:6379 check
        server REDIS02 127.0.0.2:6379 check
        server REDIS03 127.0.0.3:6379 check