Redis Replicas and High Availability
How many replicas a Redis instance runs, what high availability gives you, how your application connects, and what to change for cost or durability.
This page explains how Redis on the platform handles replicas and failover, how to choose between a single instance and a highly available one, and what your application needs to do to keep working when a replica takes over.
How Redis runs on the platform
The Catalog item is Redis (Dragonfly), a Redis-compatible engine, available on AWS and GCP. It runs inside your cluster, next to your applications.
- High availability is on by default: three replicas, one primary and two copies. If the primary fails, a replica takes over.
- Each replica runs on a separate node, so a single node failure cannot take down every copy. Three replicas therefore need three nodes in the data node pool.
- Your application connects to one address,
redis-<instance>:6379inside the same namespace (orredis-<instance>.<namespace>.svc.cluster.local), whichever replica is primary. You do not need a Sentinel-aware client.
Choose the number of replicas
| Setup | Values | Use it for |
|---|---|---|
| High availability (default) | spec.ha: true | Production |
| Two replicas | spec.replicas: 2 | A cost compromise: still survives one node failure, needs two nodes |
| Single instance | spec.ha: false | Development, or a pure cache you can afford to lose |
Set these in the Redis Component's Helm values. An explicit spec.replicas wins over spec.ha. Fewer replicas cost less, because each replica needs its own node.
Make your application survive a failover
- Reconnect and retry. During a failover, connections to the old primary drop. Use a client with automatic reconnection, and retry failed commands, so your application recovers without a restart.
- Treat a single instance as disposable. With
spec.ha: false, a restart of the one pod loses anything not saved elsewhere.
Persistence is off by default. Data survives a failover because the replicas hold copies, but if every replica restarts at once, the data is lost. Use Redis as a cache or for data you can rebuild, or raise a request to turn on scheduled snapshots.
Changes that need a request
Raise a request, with the Environment and the Redis instance name, for:
- memory or CPU for the instance;
- scheduled snapshots (persistence);
- TLS — with TLS on, clients must present a client certificate issued for the instance as well as trust its CA;
- password authentication;
- access from an application in another namespace;
- more nodes in the data pool for additional replicas.
Related articles
- Data Services — provisioning Redis and other data services from the Catalog
- Network Policies — which workloads can reach each other
- Cluster Autoscaling — node pools, including the data pool
Updated 24 days ago