> ## Documentation Index
> Fetch the complete documentation index at: https://docs-v2.ard.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Redis on cluster-n03 / cluster-n04

> Redis deployment, roles, and current limitations on the n03/n04 databases cluster.

## Redis topology

Redis is deployed as a master/replica pair across the databases cluster:

* `cluster-n03` – **Redis master**
* `cluster-n04` – **Redis 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:

```bash theme={null}
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:

```bash theme={null}
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).