Master Redis High Availability: Complete Guide to Sentinel and Cluster Deployment

Redis series articles:

Redis Operation Full Process Revealed: Design Philosophy Behind ConnectionFactory

After Hitting Disk Full and Memory Overflow in Redis, I Wrote This Single‑Node Production Guide

In early development, many projects adopt a single‑node Redis for convenience, but as user count, QPS, and data volume grow, single‑node Redis shows serious risks: disk full, memory overflow, service crashes, data loss, request avalanche, and system alerts.

If a production server suffers hardware or network issues, a single point of failure can severely reduce service availability.

Problem 1: Disk full on the Redis machine makes the service unavailable, causing timeouts. Problem 2: Memory full on the Redis machine triggers data deletion, leading to inconsistency.

Therefore, production environments must deploy clusters. Redis officially provides several cluster deployment schemes, and this article covers the following questions:

What are the mainstream deployment schemes for Redis clusters?

Detailed explanation of Redis Sentinel operation.

How to deploy Redis Sentinel with a complete failover demonstration.

Some best practices for using Redis.

If possible, consider moving to cloud native in‑memory databases; otherwise, if you manage Redis yourself, keep this guide bookmarked.

Main Deployment Schemes

In high‑concurrency scenarios, cluster deployment improves availability, scalability, and data safety. Common Redis cluster deployment schemes:

Redis Sentinel (master‑slave, high availability, automatic failover) – suitable for medium traffic (10k+ QPS).

Redis Cluster (sharding, multi‑master, high concurrency, automatic failover, data partitioning, elastic scaling) – suitable for high traffic (100k+ QPS).

Comparison Dimension

Redis Sentinel Mode

Redis Cluster Sharding Mode

Architecture Type

Master‑Slave

Multi‑Master (sharding)

Availability

High, supports automatic master‑slave switch

High, master node auto‑switch, independent shards

Concurrency Capability

Medium (suitable for 10k+ QPS)

High (suitable for 100k+ QPS)

Data Sharding

Not supported, all data resides on the master

Supported via hash slots (0‑16383)

Scalability

Hard to scale horizontally, manual node addition

Supports horizontal scaling, automatic resharding

Client Awareness

Clients obtain master address from Sentinel

Clients must support Cluster and automatically route to correct node

Deployment Complexity

Relatively simple, suitable for small teams

More complex, involves slot mapping and node coordination

Data Consistency

Eventual consistency (master‑slave sync delay)

Eventual consistency (asynchronous replication)

Failover Mechanism

Sentinel monitors master and triggers automatic failover

Cluster nodes elect new master automatically

Typical Use Cases

Medium‑size systems, cache‑heavy read‑dominant workloads

High‑concurrency e‑commerce, gaming, finance systems with distributed data

Maintenance Cost

Low‑to‑medium, mainly Sentinel configuration

Medium‑to‑high, need to manage slots, node status, resharding

Sentinel Mode Details

Sentinel consists of three roles: master, slave, and sentinel. All are Redis processes with different configurations.

Master : Provides read/write services directly to clients.

Slave : Replicates master data for backup and can take over if master fails.

Sentinel : Monitors master, detects failures, and performs automatic failover.

Recommended deployment: 1 master, 2 slaves, 3 sentinels (total 6 Redis processes).

Deploying Slave Nodes

# Create directories
mkdir -p /home/recharge/local/redis-slave-1/data
# Edit redis.conf for the slave
vim /home/recharge/local/redis-slave-1/redis.conf
# Example configuration (partial)
replicaof 192.168.0.88 6380
replica-announce-ip 123.60.83.222
replica-announce-port 6382
masterauth YourSecurePassword
requirepass YourSecurePassword

Start the slave container:

docker run --name redis-slave-1 -d \
  -p 6382:6379 \
  -v /home/recharge/local/redis-slave-1/redis.conf:/usr/local/etc/redis/redis.conf \
  -v /home/recharge/local/redis-slave-1/data:/data \
  swr.cn-east-3.myhuaweicloud.com/puup-test/redis:latest redis-server /usr/local/etc/redis/redis.conf

Check logs for successful synchronization (e.g., "Background AOF rewrite finished successfully").

Deploying Sentinel Nodes

# Create directories
mkdir -p /home/recharge/local/redis-sentinel-1/redis
mkdir -p /home/recharge/local/redis-sentinel-1/data
# Edit sentinel.conf
vim /home/recharge/local/redis-sentinel-1/redis/sentinel.conf

# sentinel.conf (essential settings)
bind 0.0.0.0
port 26379
sentinel monitor mymaster 192.168.0.88 6381 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000
dir "/data"
logfile "/data/sentinel.log"
sentinel auth-pass mymaster YourSecurePassword
sentinel announce-ip 192.168.0.100
sentinel announce-port 26379

Give the configuration file read/write permissions:

chmod -R 777 /home/recharge/local/redis-sentinel-1/redis

Start the sentinel container:

docker run --name redis-sentinel-1 -d \
  -p 26379:26379 \
  -v /home/recharge/local/redis-sentinel-1/redis:/etc/redis \
  -v /home/recharge/local/redis-sentinel-1/data:/data \
  swr.cn-east-3.myhuaweicloud.com/puup-test/redis:latest redis-server /etc/redis/sentinel.conf --sentinel

After startup, Sentinel logs show it has discovered the master and slaves, saved its configuration, and assigned an ID.

1:X 04 Mar 2025 11:26:47.545 # Redis is starting
1:X 04 Mar 2025 11:26:47.545 # Configuration loaded
1:X 04 Mar 2025 11:26:47.546 * Running mode=sentinel, port=26379.
1:X 04 Mar 2025 11:26:47.551 * Sentinel new configuration saved on disk
1:X 04 Mar 2025 11:26:47.551 # Sentinel ID is c58455eec7a2e5a46797f94c0283a9e836fe35b7
1:X 04 Mar 2025 11:26:47.551 # +monitor master mymaster 192.168.0.88 6381 quorum 2
1:X 04 Mar 2025 11:26:47.554 * +slave slave 172.17.0.1:6379 172.17.0.1 6379 @ mymaster 192.168.0.88 6381
1:X 04 Mar 2025 11:26:47.558 * +slave slave 192.168.0.100:6379 192.168.0.100 6379 @ mymaster 192.168.0.88 6381

Verifying Master‑Slave Switch

1. Check current role:

# info replication on a slave
role:slave
master_host:192.168.0.88
master_port:6381
master_link_status:up

2. Stop the master and observe Sentinel logs. Sentinel will mark the master as subjectively down (sdown) and then objectively down (odown) after quorum, elect a new master, and update configuration.

# Sample failover log excerpt
+reboot master mymaster 192.168.0.88 6381
-sdown master mymaster 192.168.0.88 6381
-odown master mymaster 192.168.0.88 6381
+new-epoch 107
+try-failover master mymaster 192.168.0.88 6381
+vote-for-leader <sentinel-id> 107
+selected-slave slave 192.168.0.88:6382 @ mymaster 192.168.0.88 6381
+promoted-slave slave 192.168.0.88:6382 @ mymaster 192.168.0.88 6382
+switch-master mymaster 192.168.0.88 6381 192.168.0.88 6382

After failover, the former slave becomes the new master, and the remaining slave replicates from it.

Best Practices

Prefer the official Redis Cluster mode over a custom master‑slave + Sentinel setup for better stability and automatic failover.

Enable both RDB and AOF persistence to protect against data loss.

Deploy at least a 3‑master‑3‑slave cluster to avoid split‑brain scenarios and ensure high availability.

Integrate monitoring and alerting (e.g., Prometheus + Grafana) for memory, disk, and connection metrics.

Regularly practice master‑slave failover and data consistency checks.

By following these guidelines, you can build a robust Redis deployment that withstands hardware failures and traffic spikes.