I have three redis servers, each one is also running a redis sentinel. The comms between the servers is encrypted with IPsec. When all IPsec connections are working, then stopping the redis replication master is recognised by the sentinels and they promote a slave to be the new master.

But when I flush IPsec (using setkey -F and setkey -FP) then the comms between the master and slaves is broken, but the sentinels do NOT promote a slave to become a new master.

The redis slaves recognise the fact that their master appears to be unavailable, because I can see this type of stuff in the redis server log:

11002:S 04 Apr 15:49:49.258 * Connecting to MASTER 192.168.106.246:6379
11002:S 04 Apr 15:49:49.259 * MASTER <-> SLAVE sync started
11002:S 04 Apr 15:50:50.425 # Timeout connecting to the MASTER...


If I subsequently activate IPsec again on the redis master, then the replication catches up, and the master remains as the master.

But while IPsec is flushed, then updates on the master can happen and they are not replicated to slaves.

Is there a setting for the sentinels that will recognise that the master is down?

I have solved the problem by adding another redis sentinel. I think the problem was that when one of the three sentinels could no longer communicate, then the remaining two could not agree to promote a slave to be the new master for replication. The redis sentinel documentation says don't try a setup with just two sentinels. But adding a fourth sentinel, then when the master, and its sentinel, became inaccessible, then there were still three sentinels left to vote up a new replication master.