1

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

我有一个 Redis 主机、一个从机和一个 Sentinel 监控它们。一切似乎都在正常工作，包括当主人被杀死时的故障转移。但是当我发出 SENTINEL FAILVER 命令时，Sentinel 会卡在 +failover-state-wait-promotion 状态几分钟。似乎奴隶没有得到提升命令。这没有任何意义，因为从 Sentinel 主机到任一 Redis 主机的网络通信似乎没有任何问题。我在 Docker 容器中运行所有 3 个过程，但我不确定这会如何导致问题。我可以从 Sentinel 主机（即从 Docker 容器内部）运行 redis-cli，并且可以远程执行 slaveof 命令。我还可以监控两个 Redis 实例并查看 SENTINEL ping 和信息请求。我查看了 master 和 slave 的日志，没有发现任何异常。看着这篇文章似乎没有任何理由让 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] 13.11 Jul 013:88 # +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] 7 月 1 日 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.5+failover-state -select-slave master redis-holt-overflow 10.19.8.2 6380
[8] 7 月 1 日 01:38:42.404 # +selected-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 * +故障转移状态-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
[8] 01 Jul 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] 7 月 1 日 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 * DB 保存在磁盘上
[20] 7 月 1 日 01:34:45.799 * RDB：写时复制使用的内存为 0 MB
[17] 7 月 1 日 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] 7 月 1 日 01:38:43.275 * pid 21 开始后台保存
[21] 7 月 1 日 01:38:43.277 * 数据库保存在磁盘上
[21] 7 月 1 日 01:38:43.277 * RDB：写入时复制使用的 0 MB 内存
[17] 7 月 1 日 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] 7 月 1 日 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] 7 月 1 日 01:34:45.948 * SYNC 的非阻塞连接触发了事件。
[14] 7 月 1 日 01:34:45.948 * 主服务器回复 PING，复制可以继续...
[14] 7 月 1 日 01:34:45.948 * 部分重新同步不可能（没有缓存的主服务器）
[14] 7 月 1 日 01:34:45.948 * 从主站完全重新同步：b912b647401917d52742c0eac3ae2f795f59f48f:1
[14] 7 月 1 日 01:34:45.960 * 主站 <-> 从站同步：从主站接收 18 个字节
[14] 7 月 1 日 01:34:45.960 * MASTER <-> SLAVE 同步：刷新旧数据
[14] 7 月 1 日 01:34:45.960 * MASTER <-> SLAVE 同步：将 DB 加载到内存中
[14] 7 月 1 日 01:34:45.960 * MASTER <-> SLAVE 同步：成功完成
[14] 7 月 1 日 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] 7 月 1 日 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] 7 月 1 日 01:38:43.426 * SYNC 的非阻塞连接触发了事件。
[14] 7 月 1 日 01:38:43.427 * 主服务器回复 PING，复制可以继续...
[14] 7 月 1 日 01:38:43.427 * 部分重新同步不可能（没有缓存的主服务器）
[14] 7 月 1 日 01:38:43.427 * 从主站完全重新同步：b912b647401917d52742c0eac3ae2f795f59f48f:10930
[14] 7 月 1 日 01:38:43.520 * 主站 <-> 从站同步：从主站接收 18 个字节
[14] 7 月 1 日 01:38:43.520 * MASTER <-> SLAVE 同步：刷新旧数据
[14] 7 月 1 日 01:38:43.520 * MASTER <-> SLAVE 同步：将 DB 加载到内存中
[14] 01 Jul 01:38:43.520 * MASTER <-> SLAVE 同步：成功完成

哨兵配置

端口 26379
pidfile "/var/run/redis-sentinel.pid"
logfile ""
daemonize no

由 CONFIG REWRITE 生成

dir "/data"
sentinel monitor redis-holt-overflow 10.19.8.2 6380 1
sentinel down-after-milliseconds redis-holt-overflow 3100
sentinel config-epoch redis-holt-overflow 0
sentinel leader-epoch redis-holt-overflow 1
sentinel known-slave redis-holt-overflow 10.19.8.3 6381
sentinel current-epoch 1

Redis 和哨兵信息：

redis_version:2.8.21 redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:551c16ab9d912477
redis_mode:standalone
os: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
hz:10
lru_clock:9642428
config_file:/usr/local/etc/redis/redis.conf

4

2 回答 2

1

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

从文档中：

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

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

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

于 2015-07-01T15:45:14.573 回答
0

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

于 2015-07-02T00:56:05.597 回答