Skip to main content

Redis topology

Redis is deployed as a master/replica pair across the databases cluster:
  • cluster-n03Redis master
  • cluster-n04Redis replica of cluster-n03
However, the client traffic pattern means the setup behaves like a single-node Redis from the application point of view: all clients connect directly to the master on 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:master
    • connected_slaves:7
Useful commands:
ssh cluster-n03
systemctl status redis-server
redis-cli INFO replication | egrep 'role|connected_slaves|master_host|master_port'

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:slave
    • master_host:94.130.9.47 (Redis on cluster-n03)
    • master_port:6379
    • connected_slaves:0
Useful commands:
ssh cluster-n04
systemctl status redis-server
redis-cli INFO replication | egrep 'role|connected_slaves|master_host|master_port'

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-n04 if 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.

Future directions

To improve Redis high availability, we can:
  1. 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.
  2. 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).