High Availability with Sentinel

What you'll walk away with

Explain the core ideas behind High Availability with Sentinel
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

Redis Sentinel provides monitoring, failure detection, leader discovery, and automated failover for non-clustered Redis. Sentinels reach consensus about leader failure and promote a replica. Deploy at least three Sentinel processes across independent failure domains, in addition to Redis data nodes.

Connect it to a real scenario

Build a lab with one leader, two replicas, and three Sentinels. Configure clients to discover the leader by service name instead of a static hostname. During a leader-kill test, measure detection, promotion, reconnect, write-error duration, and fencing of the old leader.

Sentinel provides HA and discovery, not sharding
Use an odd quorum across failure domains
Clients must support Sentinel

Try the working example

shell

SENTINEL MASTERS
SENTINEL MASTER tutorial-primary
SENTINEL REPLICAS tutorial-primary
SENTINEL SENTINELS tutorial-primary
SENTINEL GET-MASTER-ADDR-BY-NAME tutorial-primary
SENTINEL CKQUORUM tutorial-primary

You should see

You can inspect the monitored leader, replicas, peer Sentinels, and quorum health.

5-minute try-it

Design three- or five-Sentinel placement and quorum for loss of one availability zone.

One important caution

Putting every Sentinel on one host or availability zone defeats quorum during a shared failure.

Redis — Sentinel — Redis

Easy traps

Putting every Sentinel on one host or availability zone defeats quorum during a shared failure.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Design three- or five-Sentinel placement and quorum for loss of one availability zone.

You'll know it worked when: You can inspect the monitored leader, replicas, peer Sentinels, and quorum health.