Using Redis Sentinel for High Availability: Design and Implementation

Redis Sentinel is the official high‑availability solution for Redis clusters, offering automatic failover, monitoring, notification, and configuration services that reduce manual intervention and allow clients to discover the current master.

The main features of Sentinel include:

Monitoring: continuously checks the health of master and slave instances.

Notification: alerts administrators or scripts when a Redis instance fails.

Automatic failover: promotes a slave to master when the current master is down and re‑configures other slaves.

Configuration provider: clients query Sentinel for the current master address.

Sentinel is configured via sentinel.conf . A typical configuration looks like:

// [monitor name] [ip] [port] [quorum]
sentinel monitor mymaster 127.0.0.1 6379 2
// [down‑after‑milliseconds]
sentinel down-after-milliseconds mymaster 60000
// [failover timeout]
sentinel failover-timeout mymaster 180000
// [parallel syncs]
sentinel parallel-syncs mymaster 1

To start Sentinel (Redis 2.8+), run:

redis-sentinel sentinel.conf

After startup, Sentinel performs periodic checks: every 10 seconds it sends INFO to the master, every 1 second it PINGs all Redis servers, and every 2 seconds it broadcasts its view of the cluster.

It is recommended to run at least three Sentinel instances and require a quorum of two for failover decisions.

Failover notifications can be received in three ways:

Script Notification

A notification script can be specified to run when a failover occurs (max execution time 60 seconds).

sentinel notification-script mymaster /var/redis/notify.sh

A client‑reconfiguration script can be set to run after failover.

sentinel client-reconfig-script mymaster /var/redis/notifyReconfig.sh

Direct Client Subscription

Sentinel publishes failover events via Redis Pub/Sub channels (e.g., +slave ). Clients can subscribe to these channels to receive real‑time notifications. The message format is:

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

Example:

* // subscribe all events
-sdown // message type
slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

Indirect Service Reception

A separate service can listen to Sentinel events and expose an API for applications to receive callbacks, reducing coupling and improving reliability. This approach allows swapping Sentinel implementations without changing application code.

using (RedisSentinel rs = new RedisSentinel(CurrentNode.Host, CurrentNode.Port))
{
    var redisPubSub = new RedisPubSub(node.Host, node.Port);
    redisPubSub.OnMessage += OnMessage;
    redisPubSub.PSubscribe("*");
}

The article concludes that Sentinel provides a lightweight, cost‑effective HA solution, especially when resources are limited, while acknowledging that Zookeeper may be preferable when higher reliability is required.

For further details, refer to the official Sentinel documentation ( redis.io/topics/sentinel ) and the GitHub repository mushroomsir/HRedis .