sentinel monitor mymaster redis1 6379 2bind 0.0.0.0
sentinel myid XXXbind 0.0.0.0# Generated by CONFIG REWRITEport 26379dir "/data"sentinel monitor mymaster 172.21.0.2 6379 2 <- redis1 dns name resolvedsentinel config-epoch mbn 0sentinel leader-epoch mbn 0sentinel known-slave mbn 172.21.0.3 6379 <- redis1 dns name resolvedsentinel current-epoch 0
The purpose of us using sentinel is to take advantage of its ability to manage a fail over between master and their replicas in the redis cluster. But since the redis cluster can manage master/slave failover, it is kind of redundant and costly to be usingsentinel in addition.
Our decision to stop using sentinel came about as we found out that it was causing connection problems for clients to connect to the redis servers at random times. I also discovered a weird situation in which one of the slaves turned one master and it's slave both to become its slave. Though cannot confirm for sure, but i suspect sentinel might have played a hand in this weird behavior.