Redis Sentinel n'agit pas lorsque le maître tombe en panne

J'essaie de mettre en place une configuration Redis/Sentinel sur 3 nœuds, chacun d'entre eux exécutant une instance redis et une instance sentinel. Cependant, lorsque la machine maître tombe en panne, les sentinelles restantes restent là à ne rien faire, puis décident de faire de chaque esclave un esclave de lui-même, ce qui est bien sûr proche de la pire des actions possibles.

Les détails de l'installation suivent :

Les nœuds sont 10.66.5.3 , 10.66.5.4 , 10.66.5.5 .

Par défaut, le .3 est le maître (au moment de l'installation), tous les autres ont l'entrée appropriée dans le fichier /etc/redis/redis.conf fichier : slaveof 10.66.5.3 6379 . Le reste de la redis.conf n'est pas modifiée.

La configuration de départ des sentinelles est la suivante :

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

Note : J'ai laissé upstart gère le service, c'est pourquoi le drapeau de démonisation est désactivé. Les fichiers de configuration sont accessibles en écriture par leurs démons respectifs, de sorte que sentinel peut (et le fait) mettre à jour son fichier de configuration, par exemple, sans aucun problème.

La configuration fonctionne correctement tant que tous les nœuds sont en vie. L'enregistrement de quelque chose sur le maître se propagera aux esclaves et ainsi de suite.

Maintenant, lorsque j'ai choisi de fermer ( shutdown -h now ) le maître Redis à ce moment-là et laisser un peu de temps pour que le quorum se produise, la situation résultante est la suivante :

• nœud .4 est défini comme esclave de son adresse IP ( 10.66.5.4 )
• nœud .5 est défini comme esclave de 127.0.1.1

Les sentinelles font beaucoup d'allers-retours pour essayer d'élire des choses, mais ne parviennent apparemment pas à communiquer correctement entre elles après que l'une d'entre elles se soit brisée. Elles continuent également à se détecter comme étant en panne et à faire d'autres choses ridicules.

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

En cours d'exécution :

• Ubuntu 14.04
• Redis 3.0.0

Je ne sais pas trop ce qui se passe ici et je suis à court d'idées.