Redis Sentinel не предпринимает никаких действий, когда мастер падает

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

Подробности настройки приведены ниже:

Узлы 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

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