A primary node is the authoritative node in a replicated data system. It accepts data operations and provides the state that replicas copy. In Redis, the primary accepts reads and writes while replicas accept reads; in an RDS high-availability deployment, clients send requests to the primary and a standby can be promoted if it fails. section 11.6.2 section 10.5
Use the primary node according to the deployment model:
- Choose a single-shard Redis cluster with cluster mode disabled when all cached data fits on one node; synchronize the primary with one to five replicas. section 11.2.3
- Choose cluster mode enabled when data exceeds one node’s memory; each shard has a primary and may have replicas, while clients discover topology through a configuration endpoint. section 11.2.4
- Treat Redis replicas as eventually consistent because replication is asynchronous; use them to expand read capacity, not as independent write authorities. section 11.6.2
- Expect managed failover to promote a standby or replica when the primary fails; RDS updates DNS, while enabled Redis cluster mode avoids DNS-based failover. section 10.5 section 11.2.4
Sizing a Redis deployment
A 4 GB cache can use one primary with replicas when a single node has enough memory. A 22 GB cache spread across 4 GB nodes needs six shards, each with its own primary and optional replicas. section 11.2.3 section 11.2.4
Inspect the deployment layout showing one Redis primary synchronized with replica nodes in a cluster with cluster mode disabled. section 11.2.3
