Redis sentinels in same servers as master/slave?

Question

I\'ve been doing some reading on how to use Redis Sentinel, and I know it\'s possible to have 2 or more sentinels, and load balance between them when calling from the client sid

Answer 1

It all depends the level of Disaster Recovery you want to achieve, let's assume you have the following components independently of where they are hosted:

• 2 Sentinels
• 1 Master
• 1 Slave

1 Master 1+ Slaves

One host scenario

Host fails: You loose everything, bad replication scenario for most use cases.

Two host scenario

Host 1:

• (Current elected) Master
• 1 Sentinel

Host 2:

• Slave
• 1 Sentinel

It is true that in this scenario you can have the hosts fail one at a time which gives you some level of security. Just try to understand if by different server you mean physically different hosts. If these are just VMs on the same host, you do not get the same level of DR (Disaster Recovery).

Regarding your question:

I rather have the sentinels be in the same server as the master/slave to reduce latency.

Notice that Sentinels keep track of the current master and slaves, but the Redis clients do not connect to the Master VIA the Sentinels, they just get where the current master is via the Sentinels, e.g., in terms of reads and writes you're not looking into any considerable* latency gains.

Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.

(see: http://redis.io/topics/sentinel)

The way I see it the only gains you have in terms of latency are the heartbeats sent from the Master and Slaves to the sentinel. As long as you are not spreading your servers through the whole world that should be ok.

It all depends on the use cases, but it seems you would do best to keep things as separate as possible if all other things are equal (costs, distance to clients, etc).