Redis Sentinel+Docker Compose故障转移测试：stop主节点无切换问题

问题原因 #

docker compose stop redis-master和pause的核心区别在于：

• pause仅暂停容器内进程，容器网络栈保持存在，Sentinel能正常解析redis-master主机名，检测到主节点无响应后触发故障转移。
• stop会直接销毁容器网络接口，Docker内部DNS无法解析redis-master主机名，Sentinel会将解析失败判定为DNS问题，而非主节点真的不可用，因此不会触发故障转移逻辑。

解决办法 #

1. 为容器配置固定IP #

在Docker Compose中给Redis主从、Sentinel容器分配固定IP，让Sentinel通过IP而非主机名追踪节点。示例配置片段：

services:
  redis-master:
    image: redis:latest
    networks:
      redis-net:
        ipv4_address: 172.20.0.10
  redis-slave:
    image: redis:latest
    networks:
      redis-net:
        ipv4_address: 172.20.0.11
  sentinel:
    image: redis:latest
    networks:
      redis-net:
        ipv4_address: 172.20.0.12

networks:
  redis-net:
    ipam:
      config:
        - subnet: 172.20.0.0/24

同时修改Sentinel配置，用固定IP声明主节点：

sentinel monitor mymaster 172.20.0.10 6379 1

2. 调整Sentinel主机名解析配置 #

修改Sentinel配置，强制使用IP进行节点通信，规避DNS解析依赖：

sentinel resolve-hostnames no
sentinel announce-hostnames no

配置后Sentinel会直接用IP记录和检测节点，即使主节点容器被stop，也能通过IP感知到节点不可达，触发故障转移。

测试建议 #

docker compose stop属于极端场景，真实生产环境中Redis故障多为进程崩溃、资源耗尽或网络分区，而非容器直接销毁。更贴合实际的测试方式：

• 进入主节点容器执行redis-cli shutdown模拟Redis进程崩溃
• 用docker compose pause redis-master模拟节点无响应
• 断开主节点与Sentinel的网络连接模拟网络分区

这些场景下Sentinel的故障转移逻辑会正常触发，也更符合生产环境的故障情况。

内容的提问来源于stack exchange，提问作者LuK_7