师父倒台时,Redis Sentinel不采取行动

我试图在3个节点上设置Redis / Sentinel设置,每个节点都运行一个redis实例和一个sentinel实例。 但是,当主机停机时,其余的哨兵就坐在那里什么都不做,然后决定把每个奴隶都设为自己的奴隶,这当然是接近可能的更糟糕的行动。

安装细节如下:

节点是10.66.5.5

默认情况下, .3节点是主节点(在安装时),其他所有节点都在/etc/redis/redis.conf文件中具有相应的条目: slaveof 10.66.5.3 6379 。 其余的redis.conf是未修改的。

哨兵的起始configuration如下:

 daemonize no sentinel monitor myapp 10.66.5.3 6379 2 sentinel down-after-milliseconds myapp 5000 sentinel failover-timeout myapp 15000 sentinel parallel-syncs myapp 1 

注意:我让upstart处理服务,这就是为什么守护进程标志closures。 configuration文件可以通过各自的守护进程写入,所以标记可以(并且)更新其configuration文件,例如,没有问题。

只要所有节点都活着,安装程序就可以正常工作。 在主设备上注册一些东西会传播到从设备等等。

现在,当我select当时closuresRedis主服务器( shutdown -h now ),并留出一些时间来达到法定人数时,结果是:

  • 节点.4被设置为他的IP地址( 10.66.5.4
  • .5节点被设置为127.0.1.1的从127.0.1.1

哨兵做了很多来回select的东西,但显然在他们中的一个rest之后,彼此之间没有正确的沟通。 他们也不断发现自己是失望的和其他荒谬的事情。

 1744:X 12 May 17:02:32.453 # -odown master myapp 127.0.1.1 6379 1744:X 12 May 17:02:33.517 # +odown master myapp 127.0.1.1 6379 #quorum 2/2 1744:X 12 May 17:02:38.139 # +sdown slave 10.66.5.5:6379 10.66.5.5 6379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:38.358 # +sdown slave 10.66.5.4:6379 10.66.5.4 6379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:42.970 # -sdown slave 10.66.5.5:6379 10.66.5.5 6379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:43.203 # -sdown slave 10.66.5.4:6379 10.66.5.4 6379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:43.230 * -dup-sentinel master myapp 127.0.1.1 6379 #duplicate of 127.0.0.1:26379 or 3369dfeed7f6e970c4620b3689741b47ba5d9972 1744:X 12 May 17:02:43.230 * +sentinel sentinel 127.0.0.1:26379 127.0.0.1 26379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:43.280 # -odown master myapp 127.0.1.1 6379 1744:X 12 May 17:02:43.313 * -dup-sentinel master myapp 127.0.1.1 6379 #duplicate of 10.66.5.4:26379 or 3369dfeed7f6e970c4620b3689741b47ba5d9972 1744:X 12 May 17:02:43.313 * +sentinel sentinel 10.66.5.4:26379 10.66.5.4 26379 @ myapp 127.0.1.1 6379 1744:X 12 May 17:02:44.123 # +new-epoch 24 1744:X 12 May 17:02:44.125 # +vote-for-leader 3369dfeed7f6e970c4620b3689741b47ba5d9972 24 1744:X 12 May 17:02:44.409 # +odown master myapp 127.0.1.1 6379 #quorum 2/2 

正在运行:

  • Ubuntu 14.04
  • Redis 3.0.0

我不太确定那里发生了什么事情,而我正在想出点什么。

我不在PC附近testing,但由于只有两个哨兵节点,所以没有办法打破平局。

如果你只是杀死redis(并保持哨兵运行),它是否工作? 如果是这样,那就是你的问题。

redis服务器必须监听本机的IP,而不是0.0.0.0。 否则,哨兵可能会将127.0.0.1作为机器的IP之一并传播,这显然是错误的。