Redis Sentinel не предпринимает никаких действий при выходе из строя мастера

Я пытаюсь настроить Redis / Sentinel на 3 узлах, на каждом из которых запущен один экземпляр Redis и экземпляр дозорного. Однако, когда главная машина выходит из строя, оставшиеся часовые просто сидят и ничего не делают, а затем решают установить каждое подчиненное устройство в качестве подчиненного самого себя, что, конечно, близко к худшему из возможных вариантов действий.

Подробная информация о настройке:

Узлы 10.66.5.3, 10.66.5.4, 10.66.5.5.

По умолчанию .3 узел является мастером (во время установки), все остальные имеют соответствующую запись в /etc/redis/redis.conf файл: slaveof 10.66.5.3 6379. Остаток от redis.conf не модифицирован.

Начальная конфигурация дозорных выглядит следующим образом:

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 обрабатывать службу, поэтому флаг демонизации отключен. Конфигурационные файлы доступны для записи их соответствующими демонами, поэтому дозорный может (и обновляет), например, свой конфигурационный файл, без проблем.

Настройка работает нормально, пока все узлы живы. Регистрация чего-либо на ведущем устройстве будет распространяться на ведомые устройства и так далее.

Теперь, когда я выбрал выключение (shutdown -h now) мастер Redis в это время и оставьте некоторое время для возникновения кворума, в результате получится следующая ситуация:

• узел .4 установлен как подчиненный его IP-адрес (10.66.5.4)
• узел .5 настроен быть рабом 127.0.1.1

Часовые много бегают туда-сюда, пытаясь выбрать что-то, но, очевидно, не могут нормально общаться друг с другом после того, как один из них сломается. Они также продолжают определять себя как подавленные и другие нелепые вещи.

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

Я не совсем уверен, что там происходит, и у меня почти нет идей.