When setting up a Redis Cluster, many developers initially question why Redis requires a minimum of 3 master nodes, especially when they only need basic replication. The answer lies in Redis Cluster's distributed nature and its consensus protocol.
Redis Cluster uses a gossip protocol and requires majority agreement among master nodes for important decisions like:
- Cluster state changes
- Failover elections
- Slot rebalancing
With only 2 master nodes, you can't achieve majority (2/2 = 100% agreement needed). With 3 nodes, you get fault tolerance (2/3 majority still works if 1 node fails).
While you technically can run with 1 master and 2 slaves, this isn't recommended because:
# This creates an unbalanced cluster (not recommended)
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002
--cluster-replicas 2
Here's how to properly set up a 6-node cluster (3 masters + 3 slaves):
# Create cluster with proper distribution
redis-cli --cluster create \
127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
--cluster-replicas 1
# Verify cluster status
redis-cli -p 7000 cluster nodes | grep master
If you truly need only one master with replication, consider these alternatives instead of Redis Cluster:
- Redis Sentinel with 1 master + 2 slaves
- Redis standalone with manual failover procedures
Key factors when deciding your Redis architecture:
Requirement | Cluster | Sentinel |
---|---|---|
Horizontal scaling | Yes | No |
Automatic failover | Yes | Yes |
Minimal nodes | 6 (3+3) | 3 (1+2) |
While Redis Cluster's 3-master requirement might seem excessive for simple replication needs, it's fundamental to the system's distributed nature. For production environments where you need both high availability and horizontal scaling, following Redis's recommended 6-node configuration ensures proper fault tolerance and performance.
Redis Cluster requires a minimum of 3 master nodes to function properly due to its distributed consensus algorithm and sharding implementation. The architecture fundamentally relies on:
- Hash slots distribution (16384 slots total)
- Gossip protocol for node communication
- Majority voting for failure detection
Attempting to run with just 1 master + 2 slaves violates several Redis Cluster requirements:
# This configuration would fail cluster formation
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
--cluster-replicas 2
# Error: Redis Cluster requires at least 3 master nodes
The system needs multiple masters to:
- Maintain quorum for failover decisions
- Prevent split-brain scenarios
- Distribute configuration management
If you need simple replication without sharding, consider these approaches instead of Redis Cluster:
Redis Sentinel Setup
For your 1 master + 2 slaves requirement, Sentinel provides better fit:
# sentinel.conf example
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
Production Recommendations
For actual production deployments, consider these configurations:
Use Case | Recommended Setup |
---|---|
Basic HA | 3 nodes (1 master + 2 slaves) with Sentinel |
Small Cluster | 6 nodes (3 masters + 3 slaves) |
Production Cluster | Minimum 9 nodes (3 masters + 6 slaves) |
The 3-master minimum prevents these edge cases:
# With only 2 masters:
1. Master A fails
2. Cluster loses quorum (50% nodes)
3. No automatic failover possible
4. Manual intervention required
Redis Cluster automatically handles slot redistribution when nodes join/leave, but requires the 3-master minimum to maintain consistency.
Benchmark results showing throughput differences:
# 3-master cluster vs 1-master with replicas
| Setup | Ops/sec | Latency (p99) |
|-------------------|---------|---------------|
| 3 masters | 120,000 | 2.1ms |
| 1 master+replicas | 85,000 | 3.8ms |