Connecting Applications

This is the part that makes Sentinel different from a database-behind-a-proxy setup: the client discovers the primary — there is no fixed write address.

The discovery handshake

A Sentinel-aware client connects to any Sentinel and asks where the primary is:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# 1) "10.100.100.101"
# 2) "6379"

It connects there for reads and writes, and it subscribes to Sentinel's +switch-master pub/sub channel — so the instant a failover happens it learns the new address and reconnects. No restart, no config change, no human.

Configure your client with all three Sentinels

Give the client every Sentinel address (not the Redis address) so discovery still works if one Sentinel is down.

Python (redis-py):

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [("10.100.100.101", 26379),
     ("10.100.100.102", 26379),
     ("10.100.100.103", 26379)],
    socket_timeout=0.5,
    sentinel_kwargs={"password": "ChangeMe_RedisPass"},
    password="ChangeMe_RedisPass",
)

master  = sentinel.master_for("mymaster")   # always the current primary
replica = sentinel.slave_for("mymaster")    # a read replica

master.set("hello", "world")
print(replica.get("hello"))

Node.js (ioredis):

const Redis = require("ioredis");

const redis = new Redis({
  sentinels: [
    { host: "10.100.100.101", port: 26379 },
    { host: "10.100.100.102", port: 26379 },
    { host: "10.100.100.103", port: 26379 },
  ],
  name: "mymaster",
  sentinelPassword: "ChangeMe_RedisPass",
  password: "ChangeMe_RedisPass",
});

await redis.set("hello", "world");

The library handles the whole lifecycle: discover the primary, route writes there, route reads to replicas if you ask, and re-resolve automatically on +switch-master.

Do not put a TCP load balancer or VIP in front of Redis here. A proxy would hand clients a fixed address and defeat Sentinel's whole purpose — the client must reach the current primary, which only Sentinel knows. The Sentinels are the discovery layer; the client library is the failover-aware part. (A proxy like a fixed VIP belongs to other HA patterns in this series — not this one.)