Não estou perto de um PC para testar, mas como há apenas dois nós sentinela restantes, não há como quebrar o empate.
Funciona se você acabou de matar os redis (e manter a sentinela em execução)? Se assim for, esse é o seu problema.
Estou tentando configurar uma configuração do Redis / Sentinel em 3 nós, cada um executando uma instância de redis e uma sentinela. No entanto, quando a máquina mestre desce, os sentinelas remanescentes ficam ali sentados, sem fazer nada, então decidem definir cada escravo como um escravo de si mesmo, o que obviamente está próximo do pior curso de ação possível.
Detalhes sobre a configuração a seguir:
Os nós são 10.66.5.3 , 10.66.5.4 , 10.66.5.5 .
Por padrão, o nó .3 é o mestre (no momento da instalação), todos os outros têm a entrada apropriada no arquivo /etc/redis/redis.conf : slaveof 10.66.5.3 6379 . O restante do redis.conf não foi modificado.
A configuração inicial para as sentinelas é a seguinte:
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
Observação: eu deixo upstart manipular o serviço, é por isso que o sinalizador de daemonização está desativado. Os arquivos de configuração são graváveis por seus respectivos daemons, então o sentinel pode (e atualiza) seu arquivo de configuração, por exemplo, sem problemas.
A configuração funciona bem, desde que todos os nós estejam ativos. Registrar algo no mestre propagar-se-á aos escravos e assim por diante.
Agora, quando eu escolhi desligar ( shutdown -h now ) o mestre Redis naquele momento e deixar algum tempo para o quorum ocorrer, a situação resultante é:
.4 está configurado para ser um escravo de seu endereço IP ( 10.66.5.4 ) .5 está definido como escravo de 127.0.1.1
As sentinelas estão fazendo muitas idas e vindas tentando eleger coisas, mas aparentemente não conseguem se comunicar adequadamente uma com a outra depois que uma delas quebra. Eles também continuam se detectando como para baixo e outras coisas ridículas.
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
Em execução:
Não sei bem o que está acontecendo lá e estou sem ideias.
Não estou perto de um PC para testar, mas como há apenas dois nós sentinela restantes, não há como quebrar o empate.
Funciona se você acabou de matar os redis (e manter a sentinela em execução)? Se assim for, esse é o seu problema.
servidores redis devem ouvir no IP da máquina, não 0.0.0.0. Caso contrário, os sentinelas podem usar 127.0.0.1 como um dos IP da máquina e propagá-la, o que obviamente está errado.
Tags redis redis-sentinel