Redis Sentinel не восстанавливает мастер -> подчиненный до его перезапуска

Question

У меня возникают проблемы с воскрешением главного узла с Sentinel. В частности, подчиненные подчиняются должным образом, когда мастер потерян, но мастер при перезагрузке никогда не понижается в должности. Однако, если я немедленно перезапущу Sentinel, главный узел будет понижен в должности. Моя конфигурация плохая, или я пропустил что-то основное?

EDIT: Xpost с https://groups.google.com/forum/#!topic/redis-db/4AnGNssqYTw

I установками несколько виртуальных машин, как следует, все с Redis 3.1.999:

конфигурация

192.168.0.101 - Redis Slave 
192.168.0.102 - Redis Slave 
192.168.0.103 - Redis Master 
192.168.0.201 - Sentinel 
192.168.0.202 - Sentinel 

Моего Стража, как для часовых:

loglevel verbose 
logfile "/tmp/sentinel.log" 
sentinel monitor redisA01 192.168.0.101 6379 2 
sentinel down-after-milliseconds redisA01 30000 
sentinel failover-timeout redisA01 120000 

Я останавливаю redis на главном узле; как и ожидалось, Sentinel ловит его и продвигает раба к хозяину.

3425:X 08 Sep 23:47:43.839 # +sdown master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:43.896 # +odown master redisA01 192.168.0.103 6379 #quorum 2/2 
3425:X 08 Sep 23:47:43.896 # +new-epoch 53 
3425:X 08 Sep 23:47:43.896 # +try-failover master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:43.898 # +vote-for-leader 71de0d8f6250e436e1f76800cbe8cbae56c1be7c 53 
3425:X 08 Sep 23:47:43.901 # 192.168.0.201:26379 voted for 71de0d8f6250e436e1f76800cbe8cbae56c1be7c 53 
3425:X 08 Sep 23:47:43.975 # +elected-leader master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:43.976 # +failover-state-select-slave master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:44.077 # +selected-slave slave 192.168.0.102:6379 192.168.0.102 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:44.078 * +failover-state-send-slaveof-noone slave 192.168.0.102:6379 192.168.0.102 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:44.977 * +failover-state-wait-promotion slave 192.168.0.102:6379 192.168.0.102 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:44.980 - -role-change slave 192.168.0.102:6379 192.168.0.102 6379 @ redisA01 192.168.0.103 6379 new reported role is master 
3425:X 08 Sep 23:47:44.981 # +promoted-slave slave 192.168.0.102:6379 192.168.0.102 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:44.981 # +failover-state-reconf-slaves master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:45.068 * +slave-reconf-sent slave 192.168.0.101:6379 192.168.0.101 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:46.031 * +slave-reconf-inprog slave 192.168.0.101:6379 192.168.0.101 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:46.032 * +slave-reconf-done slave 192.168.0.101:6379 192.168.0.101 6379 @ redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:46.101 # -odown master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:46.101 # +failover-end master redisA01 192.168.0.103 6379 
3425:X 08 Sep 23:47:46.102 # +switch-master redisA01 192.168.0.103 6379 192.168.0.102 6379 
3425:X 08 Sep 23:47:46.103 * +slave slave 192.168.0.101:6379 192.168.0.101 6379 @ redisA01 192.168.0.102 6379 
3425:X 08 Sep 23:47:46.103 * +slave slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 

Подождите несколько минут и перезапустите Redis на прежнем главном узле. Неожиданно (для меня) узел не понижается до подчиненного.

3425:X 08 Sep 23:48:16.105 # +sdown slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 
3425:X 08 Sep 23:50:09.131 # -sdown slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 

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

3425:signal-handler (1441758237) Received SIGTERM scheduling shutdown... 
... 
3670:X 09 Sep 00:23:57.687 # Sentinel ID is 71de0d8f6250e436e1f76800cbe8cbae56c1be7c 
3670:X 09 Sep 00:23:57.687 # +monitor master redisA01 192.168.0.102 6379 quorum 2 
3670:X 09 Sep 00:23:57.690 - -role-change slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 new reported role is master 
3670:X 09 Sep 00:23:58.708 - Accepted 192.168.0.201:49731 
3670:X 09 Sep 00:24:07.778 * +convert-to-slave slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 
3670:X 09 Sep 00:24:17.801 - +role-change slave 192.168.0.103:6379 192.168.0.103 6379 @ redisA01 192.168.0.102 6379 new reported role is slave 

Answer 1

Я бы проверял несколько процессов на главном и возможную круговую репликацию. Я посмотрю на конец первой партии журналов, которую вы увидите, что он обнаруживает 103 IP как ведомый уже через запись + slave. Я попытался бы понять, почему при продвижении нового мастера уже показывает старого мастера как раба.

После перезапуска происходит реконфигурация в соответствии с предоставленными журналами перед повторным открытием ведомого устройства, после чего он обнаруживает подчиненное подчинение как ведущее устройство.

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

Редакция: неверно описанная конфигурация вашего датчика. Вы перечисляете хозяина как 103 в своем списке, но отправленный файл конфигурации отправителя указывает 101, который является подчиненным в соответствии с вашим листингом.

Также добавьте третий дозорный сигнал. Двое позволяют легко разделить мозг, и вы вполне можете видеть то, что видите.