CodeParkReplication copies data. Sentinel adds automatic failover. Cluster splits data across several primaries.
Replication copies a primary's data to one or more replicas. It is asynchronous: the primary does not wait for the replicas before it replies. Replicas can serve reads. They can also act as hot standbys, meaning copies ready to take over. But replication alone does not promote a replica when the primary dies.
Sentinel adds high availability (the system keeps working when a server fails) to a primary-replica setup. A group of Sentinel processes watches the primary. You need at least three of them, so they can reach a quorum (enough votes to agree). When they agree the primary is down, they:
- promote a replica to be the new primary
- reconfigure the other replicas to follow it
- tell clients the new primary, because clients ask Sentinel for the current primary
All data must still fit on one primary, so writes do not scale.
Cluster shards data, meaning it splits the data across several primaries. It uses 16,384 hash slots, and each primary owns some of them. Each primary has its own replicas. Failover is built in, so you do not use Sentinel with Cluster. Cluster scales memory and write throughput. The cost is some limits:
- Multi-key operations need all keys in the same slot.
- Only database 0 is available.
In short: pick Sentinel when your data fits on one node and you need failover. Pick Cluster when it does not fit.
- Replication makes async copies and scales reads, but has no automatic failover.
- Sentinel watches one primary, votes with a quorum and fails over automatically.
- Clients find the current primary by asking Sentinel.
- Cluster shards data over 16,384 slots and has failover built in.
- Cluster limits multi-key operations and uses only database 0.