Redis topology
Redis is deployed as a master/replica pair across the databases cluster:cluster-n03– Redis mastercluster-n04– Redis replica ofcluster-n03
cluster-n03.
Redis on cluster-n03 (master)
- Version:
redis-cli 6.2.6 - Service:
redis-server.service(enabled, active) - Config:
/etc/redis/redis.conf - Bind / port:
0.0.0.0:6379 - Replication info (from
INFO replication):role:masterconnected_slaves:7
Redis on cluster-n04 (replica)
- Version:
redis-cli 6.2.6 - Service:
redis-server.service(enabled, active)` - Bind / port:
0.0.0.0:6379 - Replication info:
role:slavemaster_host:94.130.9.47(Redis oncluster-n03)master_port:6379connected_slaves:0
Current limitations
- All application clients connect directly to Redis on
cluster-n03. - There is no HAProxy or Sentinel layer in the Redis client path today.
- As a result:
- There is no automatic failover to
cluster-n04if the master fails. - Promotion of the replica must be done manually, with client endpoints updated accordingly.
- Redis is effectively a single point of failure for dependent workloads.
- There is no automatic failover to
Future directions
To improve Redis high availability, we can:-
Harden the current master/replica pair
- Actively monitor the replica on
cluster-n04. - Introduce Sentinel or another HA mechanism that:
- Detects master failure.
- Promotes the replica.
- Exposes a stable endpoint (DNS/VIP or proxy) to clients.
- Actively monitor the replica on
-
Move to a dedicated Redis HA / cluster setup
- Use Redis Cluster or managed Redis with built-in redundancy.
- Ensure client libraries are compatible with the chosen mode.
- Plan a controlled migration (snapshot, sync, cutover, rollback plan).

