Designing High Availability for Redis with Sentinel

Redis Sentinel

Sentinel Introduction

Sentinel is the official Redis high‑availability solution that can automatically perform failover, monitor master/slave status, and notify clients of state changes, reducing manual intervention.

Key functions include:

Monitoring – continuously checks the health of masters and slaves.

Notification – alerts administrators or scripts when an instance goes down.

Automatic failover – promotes a slave to master when the current master fails.

Configuration provider – clients can query Sentinel for the current master address.

Sentinel Configuration

Sentinel runs as a special‑mode Redis server; its behavior is defined in sentinel.conf:

// [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

Start Sentinel (Redis 2.8+): redis-sentinel sentinel.conf After startup, Sentinel:

Every 10 seconds sends INFO to the monitored master.

Every 1 second pings all Redis nodes (including other Sentinels).

Every 2 seconds broadcasts its view of the master/slave topology.

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

Three Ways to Receive Failover Notifications

Script Notification

During a failover, Sentinel can invoke a user‑defined script (max execution time 60 s).

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

After failover, a client‑reconfiguration script can be called.

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

Client Direct Subscription

Sentinel publishes events via Redis Pub/Sub channels (e.g., +slave). Clients subscribe to these channels to receive real‑time messages.

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

Example message:

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

Sample C# subscription code:

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

Indirect Service Reception

A dedicated service consumes Sentinel messages and exposes an API for application servers to call, reducing coupling and improving reliability.

Applications no longer need to handle subscription failures.

The service can poll Redis status as a fallback.

Example API endpoint for applications to refresh their Redis connections: http://127.0.0.1/redis/notify.api The service notifies the application by POSTing to the above endpoint:

httprequest.post("http://127.0.0/redis/notify.api");

Overall Design Recommendation

The third method (indirect service) is recommended for production; a flow diagram (omitted here) illustrates the interaction between Sentinels, the monitoring service, and client applications.

Conclusion

Sentinel provides a lightweight, cost‑effective HA solution for Redis. While Zookeeper offers richer features, Sentinel is suitable when resources are limited and still allows future extensibility.

Official Sentinel documentation: https://redis.io/topics/sentinel