Redis Sentinel手动故障切换命令超时

Redis Sentinel手动故障切换命令超时

我有一个Redis master，一个slave，一个Sentinel监视它们。 一切似乎都正常工作，包括主人死亡时的故障转移。 但是，当我发出SENTINEL FAILVER命令时，Sentinel陷入了状态+ failover-state-wait-promotion几分钟。 似乎奴隶没有获得晋升的命令。 这是没有道理的，因为从Sentinel主机到任一Redis主机的networking通信似乎没有任何问题。 我正在运行Docker容器中的所有3个过程，但是我不确定这会怎样导致这个问题。 我可以从Sentinel主机（即从Docker容器内部）运行redis-cli，并可以远程执行slaveof命令。 我也可以监控两个Redis实例，并查看SENTINEL ping和info请求。 我看着主人和奴隶的日志，没有看到任何exception。 看这篇文章，似乎没有任何理由为什么Sentinel会认为Redis实例是无效的。

我对Sentinel相当有经验，但对Docker来说却是新的。 不确定如何继续确定问题是什么。 有任何想法吗？

前哨日志

[8] 01 Jul 01：36：57.317＃Sentinel runid是c337f6f0dfa1d41357338591cd0181c07cb026d0
[8] 01 Jul 01：38：13.135＃+ monitor master redis-holt-overflow 10.19.8.2 6380 quorum 1
[8] 01 Jul 01：38：13.135＃+ set master redis-holt-overflow 10.19.8.2 6380毫秒后3100
[7] 01 Jul 01：38：13.199 * + slave slave 10.19.8.3:6381 10.19.8.3 6381 @ redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.288＃执行用户请求的“redis-holt-overflow”的FAILOVER
[8] 01 Jul 01：38：42.288＃+ new-epoch 1
[8] 01 Jul 01：38：42.288＃+ try-failover master redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.352＃+ vote-for-leader c337f6f0dfa1d41357338591cd0181c07cb026d0 1
[8] 01 Jul 01：38：42.352＃+当选领袖大师redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.352＃+ failover-state-select-slave master redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.404＃+select从奴隶10.19.8.3:6381 10.19.8.3 6381 @ redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.404 * + failover-state-send-slaveof -noone slave 10.19.8.3:6381 10.19.8.3 6381 @ redis-holt-overflow 10.19.8.2 6380
[8] 01 Jul 01：38：42.488 * + failover-state-wait-promotion slave 10.19.8.3:6381 10.19.8.3 6381 @ redis-holt-overflow 10.19.8.2 6380
[7] 01 Jul 01：41：42.565＃-failover-abort-slave-timeout master redis-holt-overflow 10.19.8.2 6380

Redis Master Log

[17] 01 Jul 01：13：58.251＃服务器启动，Redis版本2.8.21
[17] 01 Jul 01：13：58.252＃警告overcommit_memory被设置为0！ 在低内存条件下后台保存可能会失败。 要解决这个问题，请在/etc/sysctl.conf中添加'vm.overcommit_memory = 1'，然后重新启动或运行'sysctl vm.overcommit_memory = 1'命令使其生效。
[17] 01 Jul 01：13：58.252＃警告你在内核中启用了透明巨大页面（THP）支持。 这将导致Redis的延迟和内存使用问题。 要解决这个问题，请以超级用户身份运行“echo never> / sys / kernel / mm / transparent_hugepage / enabled”命令，并将其添加到/etc/rc.local中，以便在重新启动后保留设置。 在THP禁用后，必须重新启动Redis。
[07] 01 Jul 01：13：58.252＃警告：由于/ proc / sys / net / core / somaxconn被设置为128的较低值，所以511的TCP backlog设置无法执行。
[17] 01 Jul 01：13：58.252 *从磁盘加载的数据库：0.000秒
[17] 01 Jul 01：13：58.252 *服务器现在已准备好接受端口6380上的连接
[17] 01年7月1日：34：45.796 *奴隶10.196.88.30:6381要求同步
[17] 01 Jul 01：34：45.796 *由从站10.196.88.30:6381请求完全重新同步
[17] 01 Jul 01：34：45.796 *为目标磁盘启动SYNC的BGSAVE
[17] 01 Jul 01：34：45.797 *后台保存由pid 20开始
[20] 01年7月1日：34：45.798 * DB保存在磁盘上
[20] 01 Jul 01：34：45.799 * RDB：写入时使用的内存为0 MB
[17] 01 Jul 01：34：45.808 *保存背景成功
[17] 01 Jul 01：34：45.808 *同步从站10.196.88.30:6381成功
[17] 01 Jul 01：38：42.343＃与奴隶10.196.88.30:6381失去联系。
[17] 01年7月1日：38：43.275 *奴隶10.196.88.30:6381要求同步
[17] 01 Jul 01：38：43.275 *从站10.196.88.30:6381请求完全重新同步
[17] 01 Jul 01：38：43.275 *为目标磁盘启动SYNC的BGSAVE
[17] 01 Jul 01：38：43.275 *后台保存由pid 21开始
[21] 01 Jul 01：38：43.277 * DB保存在磁盘上
[21] 01 Jul 01：38：43.277 * RDB：写入时使用的内存为0 MB
[17] 01 Jul 01：38：43.368 *后台保存成功终止
[17] 01 Jul 01：38：43.368 *同步从站10.196.88.30:6381成功

Redis Slave日志

[14] 01 Jul 01：15：51.435＃服务器启动，Redis版本2.8.21
[14] 01 Jul 01：15：51.435＃警告overcommit_memory被设置为0！ 在低内存条件下后台保存可能会失败。 要解决这个问题，请在/etc/sysctl.conf中添加'vm.overcommit_memory = 1'，然后重新启动或运行'sysctl vm.overcommit_memory = 1'命令使其生效。
[07] 01 Jul 01：15：51.435＃警告你在内核中启用了透明巨大页面（THP）支持。 这将导致Redis的延迟和内存使用问题。 要解决这个问题，请以超级用户身份运行“echo never> / sys / kernel / mm / transparent_hugepage / enabled”命令，并将其添加到/etc/rc.local中，以便在重新启动后保留设置。 在THP禁用后，必须重新启动Redis。
[07] 01 Jul 01：15：51.435＃警告：由于/ proc / sys / net / core / somaxconn被设置为128的较低值，所以511的TCP backlog设置无法执行。
[14] 01 Jul 01：15：51.435 *从磁盘加载的数据库：0.000秒
[14] 01 Jul 01：15：51.435 *服务器现在准备好接受端口6381上的连接
[14] 01 Jul 01：34：45.088 * SLAVE OF 10.196.88.29：6380启用（用户请求）
[14] 01 Jul 01：34：45.947 *连接到MASTER 10.196.88.29：6380
[14] 01 Jul 01：34：45.947 * MASTER < – >从属同步开始
[14] 01 Jul 01：34：45.948 * SYNC的非阻塞连接触发事件。
[14] 01 Jul 01：34：45.948 *师父回复PING，复制可以继续…
[14] 01年7月1日：34：45.948 *部分重新同步不可能（没有caching的主）
[14] 01 Jul 01：34：45.948 *与主机完全同步：b912b647401917d52742c0eac3ae2f795f59f48f：1
[14] 01 Jul 01：34：45.960 * MASTER < – > SLAVE同步：从主机接收18个字节
[14] 01 Jul 01：34：45.960 * MASTER < – > SLAVE sync：刷新旧数据
[14] 01 Jul 01：34：45.960 * MASTER < – > SLAVE sync：将DB加载到内存中
[14] 01 Jul 01：34：45.960 * MASTER < – > SLAVE同步：成功完成
[14] 01年7月1日：38：42.495＃与主丢失连接。
[14] 01 Jul 01：38：42.495 *caching断开的主状态。
[14] 01 Jul 01：38：42.495 *放弃以前caching的主状态。
[14] 01 Jul 01：38：42.495 *启用MASTER MODE（用户请求）
[14] 01 Jul 01：38：42.495＃CONFIG REWRITE成功执行。
[14] 01 Jul 01：38：42.506 * SLAVE OF 10.196.88.29：6380启用（用户请求）
[14] 01 Jul 01：38：43.425 *连接到MASTER 10.196.88.29：6380
[14] 01 Jul 01：38：43.426 * MASTER < – > SLAVE同步开始
[14] 01 Jul 01：38：43.426 * SYNC的非阻塞连接触发事件。
[14] 01 Jul 01：38：43.427 *师父回答PING，复制可以继续…
[14] 01 Jul 01：38：43.427 *部分重新同步不可能（没有caching的主机）
[14] 01 Jul 01：38：43.427 *与主机完全同步：b912b647401917d52742c0eac3ae2f795f59f48f：10930
[14] 01 Jul 01：38：43.520 * MASTER < – > SLAVE同步：从主机接收18个字节
[14] 01 Jul 01：38：43.520 * MASTER < – > SLAVE sync：刷新旧数据
[14] 01 Jul 01：38：43.520 * MASTER < – > SLAVE sync：将DB加载到内存中
[14] 01 Jul 01：38：43.520 * MASTER < – > SLAVE同步：成功完成

哨兵configuration

港口26379
pidfile“/var/run/redis-sentinel.pid”
日志文件“”
守护程序没有

由CONFIG REWRITE生成

目录“/ data”
哨兵监控器redis-holt-overflow 10.19.8.2 6380 1
哨兵在几毫秒后重新启动溢出3100
哨兵config-epoch redis-holt-overflow 0
哨兵领袖 – 时代redis-holt-overflow 1
哨兵已知 – 奴隶redis-holt溢出10.19.8.3 6381
哨兵当前时代1

Redis＆Sentinel信息：

redis_version：2.8.21 redis_git_sha1：00000000
redis_git_dirty：0
redis_build_id：551c16ab9d912477
redis_mode：独立
操作系统：Linux 3.10.0-123.8.1.el7.x86_64 x86_64
arch_bits：64
multiplexing_api：epoll的
gcc_version：4.7.2
PROCESS_ID：13
run_id：7e1a1b6c844a969424d16f3efa116707ea7a60bf
TCP_PORT：6380
uptime_in_seconds：1312
uptime_in_days：0
赫兹：10
lru_clock：9642428
CONFIG_FILE：/usr/local/etc/redis/redis.conf

Answer 1

看起来你正在遇到“dockernetworking”问题。 如果你看看你的日志，他们显示不同的IP地址。 这是由于在发现过程中检测到连接了哪些IP。 这些在不同的docker主机上吗？

从文档：

由于Sentinel使用主设备INFO输出信息自动检测从设备，因此检测到的从设备将无法访问，并且Sentinel永远不能对主设备进行故障切换，因为从系统的angular度来看没有好的从设备，所以目前没有除非您指示Docker映射端口1：1，否则可以使用Sentinel监视与Docker一起部署的一组主从实例。

对于哨兵，可以在https://registry.hub.docker.com/u/joshula/redis-sentinel/上finddocker镜像，它显示了使用announce-ip和bind进行设置&#x3002;

有关更多详细信息，请参阅http://redis.io/topics/sentinel，特别是Docker部分，详细介绍如何在Docker中设置处理情况&#x3002;

Answer 2

狗走了，是的，这是脚本之一。 在这两个Redis事件都是主人的过渡时期，这基本上是触发的，并且抢先地将提升的奴隶回复到奴隶地位。 这是一个漫长的一周。