Redis 哨兵故障转移不起作用
Redis sentinel failover not working
我在同一台机器上设置了 Redis sentinel,在端口 7000、7001 和 7002(一个主服务器和两个从服务器)上设置了三个服务器,在端口 26379、26380 和 26381 上设置了三个服务器(ubuntu VM ).
当我启动它们时,根据日志,一切看起来都很好,当我对哨兵执行 运行 INFO 命令时,看起来也很健康。但是当我放下主人时(通过 Ctrl+C 或 redis-cli SLEEP 命令使其停止工作),none 的从属实例被引入为新的主人并且哨兵尝试提名并连接到已经死亡的高手实例!我的配置如下:
大师:
port 7000
protected-mode no
从机#1:
port 7001
slaveof 10.75.196.216 7000
从机#2:
port 7002
slaveof 10.75.196.216 7000
哨兵 #1:
port 26379
protected-mode no
sentinel myid bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
sentinel config-epoch themaster 0
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/master"
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-sentinel themaster 10.75.196.216 26380 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel known-sentinel themaster 10.75.196.216 26381 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel current-epoch 322
哨兵#2:
port 26380
protected-mode no
sentinel myid 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/slave1"
sentinel config-epoch themaster 0
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-sentinel themaster 10.75.196.216 26381 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel known-sentinel themaster 10.75.196.216 26379 bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel current-epoch 322
哨兵#3:
port 26381
protected-mode no
sentinel myid 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/slave2"
sentinel config-epoch themaster 0
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-sentinel themaster 10.75.196.216 26379 bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel known-sentinel themaster 10.75.196.216 26380 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel current-epoch 322
主控制台日志:
Sentinel #1 控制台日志:
Sentinel #1 信息命令结果:
master 关闭后 Sentinel #1 日志:
我的配置有什么问题?
提前致谢。
好的,如果你注意到 sentinel 日志,当它启动时,甚至在主实例停止工作之前,它说有两个从属实例已关闭:
可能这就是为什么 none 的奴隶足以成为新的主人,我们看到 -failover-abort-no-good-slave 错误master 关闭后的哨兵日志。
所以,因为我记得我遇到了以下错误:
(error) READONLY You can't write against a read only slave
当我尝试通过 redis-cli 将密钥设置到从属节点时,我决定通过将以下行放入从属配置文件(两者)中来修复此 READONLY 错误:
slave-read-only no
并且通过修复这部分并重新启动所有内容,+sdown slave 错误不再出现在哨兵日志中,主要问题也已修复。 Sentinels 现在可以在 master 宕机事件时切换到新的 slave 实例。
正如我在互联网上看到的那样,另一个人遇到了类似的 +sdown 问题,但他的问题是身份验证。
我感谢所有分享知识和经验的人。希望这对某人有所帮助。
我在同一台机器上设置了 Redis sentinel,在端口 7000、7001 和 7002(一个主服务器和两个从服务器)上设置了三个服务器,在端口 26379、26380 和 26381 上设置了三个服务器(ubuntu VM ).
当我启动它们时,根据日志,一切看起来都很好,当我对哨兵执行 运行 INFO 命令时,看起来也很健康。但是当我放下主人时(通过 Ctrl+C 或 redis-cli SLEEP 命令使其停止工作),none 的从属实例被引入为新的主人并且哨兵尝试提名并连接到已经死亡的高手实例!我的配置如下:
大师:
port 7000
protected-mode no
从机#1:
port 7001
slaveof 10.75.196.216 7000
从机#2:
port 7002
slaveof 10.75.196.216 7000
哨兵 #1:
port 26379
protected-mode no
sentinel myid bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
sentinel config-epoch themaster 0
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/master"
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-sentinel themaster 10.75.196.216 26380 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel known-sentinel themaster 10.75.196.216 26381 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel current-epoch 322
哨兵#2:
port 26380
protected-mode no
sentinel myid 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/slave1"
sentinel config-epoch themaster 0
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-sentinel themaster 10.75.196.216 26381 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel known-sentinel themaster 10.75.196.216 26379 bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel current-epoch 322
哨兵#3:
port 26381
protected-mode no
sentinel myid 8497ee90c1e4525c0f957407fefa77427f427e0d
sentinel monitor themaster 10.75.196.216 7000 2
sentinel down-after-milliseconds themaster 3000
sentinel failover-timeout themaster 5000
sentinel parallel-syncs themaster 2
# Generated by CONFIG REWRITE
dir "/home/bob/app/sentinel-test/slave2"
sentinel config-epoch themaster 0
sentinel leader-epoch themaster 322
sentinel known-slave themaster 10.75.196.216 7001
sentinel known-slave themaster 10.75.196.216 7002
sentinel known-sentinel themaster 10.75.196.216 26379 bdddadb6e825065398be0bae214891d7ccbd6e2a
sentinel known-sentinel themaster 10.75.196.216 26380 181fb84351d6b96e0120bfa68331738ef111c49f
sentinel current-epoch 322
主控制台日志:
Sentinel #1 控制台日志:
Sentinel #1 信息命令结果:
master 关闭后 Sentinel #1 日志:
我的配置有什么问题?
提前致谢。
好的,如果你注意到 sentinel 日志,当它启动时,甚至在主实例停止工作之前,它说有两个从属实例已关闭:
可能这就是为什么 none 的奴隶足以成为新的主人,我们看到 -failover-abort-no-good-slave 错误master 关闭后的哨兵日志。
所以,因为我记得我遇到了以下错误:
(error) READONLY You can't write against a read only slave
当我尝试通过 redis-cli 将密钥设置到从属节点时,我决定通过将以下行放入从属配置文件(两者)中来修复此 READONLY 错误:
slave-read-only no
并且通过修复这部分并重新启动所有内容,+sdown slave 错误不再出现在哨兵日志中,主要问题也已修复。 Sentinels 现在可以在 master 宕机事件时切换到新的 slave 实例。
正如我在互联网上看到的那样,另一个人遇到了类似的 +sdown 问题,但他的问题是身份验证。
我感谢所有分享知识和经验的人。希望这对某人有所帮助。