What is Redis Sentinel, and which problems does it solve for a Redis deployment?

## The problem A plain Redis master with replicas gives you read scaling and a warm copy of the data, but nothing automatic happens when the master dies. Somebody has to notice, choose a replica, run `REPLICAOF NO ONE` on it, repoint the other replicas, and tell every application instance the new address. Sentinel is the component that does all of this without a human. ## What Sentinel is, concretely Sentinel is the *same binary* as the Redis server started in a different mode (`redis-sentinel sentinel.conf`, or `redis-server sentinel.conf --sentinel`). It speaks the normal Redis protocol on its own port (26379 by default) but serves a small command set (`SENTINEL ...`, `PING`, `SUBSCRIBE`, ...) instead of the data commands. **No application data ever passes through Sentinel** — it is a control plane, not a proxy. Clients still open connections directly to the Redis master. You run **several** Sentinels — three is the usual minimum — on hosts that fail independently. They form their own small distributed system so that a single Sentinel's opinion (or a single Sentinel's death) cannot trigger or block a failover. ## Topology and discovery You only configure the master: ``` sentinel monitor mymaster 10.0.0.10 6379 2 ``` From there Sentinel bootstraps the rest of the picture: - It runs `INFO` against the master every ~10 seconds; the reply lists the connected replicas, so **replicas are auto-discovered**. - Sentinels find *each other* by publishing to and subscribing to the `__sentinel__:hello` Pub/Sub channel on the monitored Redis instances. So you never list Sentinels in each other's config; they gossip through Redis itself. Sentinel **rewrites its own config file** as it learns replicas, other Sentinels, and after every failover (`sentinel monitor` line updated to the new master). This is normal and must not be prevented — the config file is Sentinel's persistent state. ## The four jobs 1. **Monitoring** — periodic `PING`, `INFO`, and hello messages to master, replicas, and other Sentinels. 2. **Notification** — every state change is published on Sentinel's Pub/Sub channels (`+sdown`, `+odown`, `+switch-master`, `+failover-end`, ...). `notification-script` can page a human. 3. **Automatic failover** — subjective down → objective down by quorum → leader election among Sentinels → replica promotion → reconfiguration of the surviving replicas and of the old master when it returns (it comes back as a replica of the new master). 4. **Configuration provider** — the client-facing part. An application asks any Sentinel `SENTINEL get-master-addr-by-name mymaster` and connects to whatever it returns; well-written clients also subscribe to `+switch-master` so they drop stale connections immediately. ## Client responsibility Sentinel only works end to end if clients are **Sentinel-aware**. Jedis/Lettuce/redis-py/go-redis all ship a Sentinel connection mode where you configure the *list of Sentinel addresses plus the master name* rather than the master's host. If you point your app at a fixed master IP, the failover will still happen and your app will still be broken — a very common production mistake. The alternative is a virtual IP or a DNS record updated by the `client-reconfig-script` hook Sentinel invokes on failover, but native Sentinel clients are the standard answer. ## What Sentinel deliberately does not do - **No sharding.** The whole dataset lives on one master; you get HA, not horizontal write scale or memory scale. That is Redis Cluster's job. - **No proxying or load balancing.** Sentinel does not sit in the data path, so it adds no latency and is not a throughput bottleneck — but it also cannot route reads for you. - **No strong durability.** Redis replication is asynchronous: writes acknowledged by the master may not have reached the promoted replica, so a failover can silently lose the last few milliseconds of writes. `min-replicas-to-write` / `min-replicas-max-lag` narrow this window by refusing writes when not enough replicas are keeping up, but never close it. - **No protection against a partitioned old master.** An isolated master keeps accepting writes from clients stuck on its side until it notices it has too few replicas; those writes are discarded when it rejoins as a replica. ## When you would choose it Sentinel is the right fit when a single master comfortably holds the dataset and the requirement is "survive a node loss without a human". If you need more memory or write throughput than one node provides, you want Cluster (which has its own failover built in and does not use Sentinel). Managed offerings usually hide one or the other behind an endpoint.