Redis Sentinel 手动故障转移命令超时答案

【问题标题】：Redis Sentinel manual failover command timesoutRedis Sentinel 手动故障转移命令超时
【发布时间】：2015-09-18 01:11:04
【问题描述】：

Redis Sentinel 手动故障转移命令超时

我有一个 Redis master、一个 slave 和一个 Sentinel 监控它们。一切似乎都在正常工作，包括当主人被杀死时的故障转移。但是当我发出 SENTINEL FAILVER 命令时，Sentinel 会卡在 +failover-state-wait-promotion 状态几分钟。似乎奴隶没有得到提升命令。这没有任何意义，因为从 Sentinel 主机到任一 Redis 主机的网络通信似乎没有任何问题。我在 Docker 容器中运行所有 3 个过程，但我不确定这会如何导致问题。我可以从 Sentinel 主机（即从 Docker 容器内部）运行 redis-cli，并且可以远程执行 slaveof 命令。我还可以监控两个 Redis 实例并查看 SENTINEL ping 和信息请求。我查看了 master 和 slave 的日志，没有发现任何异常。查看THIS 的帖子，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 down-after-milliseconds 3100
[8] 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' 的故障转移
[8] 7 月 1 日 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] 7 月 1 日 01:38:42.352 # +vote-for-leader c337f6f0dfa1d41357338591cd0181c07cb026d0 1
[8] 01 Jul 01:38:42.352 # +elected-leader master 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 # +selected-slave slave 10.19.8.3:6381 10.19.8.3 6381 @ redis-holt-overflow 10.19.8.2 6380
[8] 7 月 1 日 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] 7 月 1 日 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
[8] 7 月 1 日 01:41:42.565 # -failover-abort-slave-timeout master redis-holt-overflow 10.19.8.2 6380

Redis 主日志

[17] 01 Jul 01:13:58.251 # 服务器已启动，Redis 版本 2.8.21
[17] 01 Jul 01:13:58.252 # 警告 overcommit_memory 设置为 0！在内存不足的情况下，后台保存可能会失败。要解决此问题，请将“vm.overcommit_memory = 1”添加到 /etc/sysctl.conf，然后重新启动或运行命令“sysctl vm.overcommit_memory=1”以使其生效。
[17] 01 Jul 01:13:58.252 # 警告你的内核中启用了透明大页面 (THP) 支持。这将在 Redis 中产生延迟和内存使用问题。要解决此问题，请以 root 身份运行命令“echo never > /sys/kernel/mm/transparent_hugepage/enabled”，并将其添加到您的 /etc/rc.local 以便在重新启动后保留设置。禁用 THP 后必须重新启动 Redis。
[17] 01 Jul 01:13:58.252 # WARNING: TCP backlog 设置无法强制执行 511，因为 /proc/sys/net/core/somaxconn 设置为较低的值 128。
[17] 7 月 1 日 01:13:58.252 * 从磁盘加载的数据库：0.000 秒
[17] 01 Jul 01:13:58.252 * 服务器现在准备好接受端口 6380 上的连接
[17] 7 月 1 日 01:34:45.796 * 从站 10.196.88.30:6381 请求同步
[17] 7 月 1 日 01:34:45.796 * 从站 10.196.88.30:6381 请求完全重新同步
[17] 7 月 1 日 01:34:45.796 * 启动 BGSAVE for SYNC 与目标：磁盘
[17] 7 月 1 日 01:34:45.797 * 由 pid 20 开始后台保存
[20] 7 月 1 日 01:34:45.798 * 数据库保存在磁盘上
[20] 7 月 1 日 01:34:45.799 * RDB：写时复制使用的内存为 0 MB
[17] 01 Jul 01:34:45.808 * 后台保存成功终止
[17] 7 月 1 日 01:34:45.808 * 与从站 10.196.88.30:6381 同步成功
[17] 01 Jul 01:38:42.343 # 与从站 10.196.88.30:6381 的连接丢失。
[17] 7 月 1 日 01:38:43.275 * 从站 10.196.88.30:6381 请求同步
[17] 7 月 1 日 01:38:43.275 * 从站 10.196.88.30:6381 请求完全重新同步
[17] 7 月 1 日 01:38:43.275 * 启动 BGSAVE for SYNC 与目标：磁盘
[17] 01 Jul 01:38:43.275 * 后台保存由 pid 21
[21] 7 月 1 日 01:38:43.277 * 数据库保存在磁盘上
[21] 7 月 1 日 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 从属日志

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

哨兵配置

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

由 CONFIG REWRITE 生成

目录“/数据”
哨兵监控 redis-holt-overflow 10.19.8.2 6380 1
毫秒后哨兵下降 redis-holt-overflow 3100
哨兵配置-epoch redis-holt-overflow 0
哨兵领导者时代 redis-holt-overflow 1
sentinel known-slave redis-holt-overflow 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
拱位：64
multiplexing_api:epoll
gcc_version:4.7.2
进程 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

【问题讨论】：

标签： redis docker redis-sentinel

【解决方案1】：

您似乎遇到了“docker network”问题。如果您查看日志，它们会显示不同的 IP。这是由于在发现期间检测到连接的 IP。这些在不同的 docker 主机上吗？

来自文档：

由于 Sentinel 使用 masters INFO 输出信息自动检测从站，因此检测到的从站将无法访问，并且 Sentinel 永远无法故障转移主站，因为从系统的角度来看没有好的从站，所以有目前无法使用 Sentinel 监控一组使用 Docker 部署的主从实例，除非您指示 Docker 以 1:1 映射端口。

对于哨兵，可以在https://registry.hub.docker.com/u/joshula/redis-sentinel/ 找到一个 docker 映像，其中显示了使用announce-ip 和绑定来设置它。

有关更多详细信息，请参阅http://redis.io/topics/sentinel 特别是 Docker 部分，其中详细介绍了如何在 Docker 中进行设置以处理这种情况。

【讨论】：

是的，好点。但我正在将我的端口一对一映射。谢谢，不过你的想法！
嗯，您通过发现获得的 IP 地址与配置中的不同。例如，您配置说主服务器位于 10.19.8.2，但 Redis 从服务器认为它位于 10.196.88.29，主服务器认为从服务器位于 10.196.88.30 而不是 10.19.8.3。通过 sentinel failure 命令看到“丢失的连接”条目并不能与手动操作相提并论。另请注意，有些东西告诉奴隶要从属 10.196.88.29 而不是 10.19.8.2。如果您是 1:1 映射，您将使用主机的 IP，而不是容器。
噢，很抱歉，这是我弄乱了 IP 地址。只是一个糟糕的复制/粘贴工作。
然而我确实注意到我有第二个 Docker 容器在主实例和从实例旁边运行。这些其他 Docker 容器正在监视 Redis 实例，并基本上充当健康检查以与 Consul 同步。如果我关闭这些第二个 Docker 容器，则 Sentinel 手动故障转移会按预期恢复运行。因此，Docker 和 Sentinel 之间似乎存在一些微妙的交互。仍在调查，一旦我弄清楚了，我会发布我发现的内容。再次感谢真实。

【解决方案2】：

狗走了，是的，这是脚本之一。它本质上是在两个 Redis 实例都是主实例并抢先将提升的从站恢复为从站状态的过渡时期触发的。这是漫长的一周。

【讨论】：