> ## 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.

# Databases cluster (n03 / n04)

> Overview of the n03/n04 databases cluster, access, firewall rules, and links to per-service documentation.

## Overview

The **databases cluster** consists of two nodes:

* `cluster-n03` (`node03.cluster.devops.arabiaweather.com`)
* `cluster-n04` (`node04.cluster.devops.arabiaweather.com`)

They host the core data services for internal platforms:

* **HAProxy** load balancers ([details](./haproxy))
* **MySQL** 5.7 ([details](./mysql))
* **Redis** 6.2 ([details](./redis))
* **MongoDB** 3.x ([details](./mongodb))
* **Consul** agents used by Traefik and others ([details](./consul-traefik))

Traffic to these services is controlled both at the **service level** (bind IPs/ports) and at the **infrastructure level** via server-groups / security groups that restrict which networks can reach the cluster.

An important caveat today is that **Redis is effectively single‑writer on `cluster-n03`**, even though a replica exists on `cluster-n04`. Application clients connect directly to `cluster-n03`, and HAProxy/Sentinel are **not** providing automated failover.

## Access & SSH

Access to the nodes is via SSH using pre-configured hosts in `~/.ssh/config`:

* `cluster-n03` → `node03.cluster.devops.arabiaweather.com`
* `cluster-n04` → `node04.cluster.devops.arabiaweather.com`

Examples:

```bash theme={null}
ssh cluster-n03
ssh cluster-n04
```

Authentication is done with the shared `~/.ssh/ydabain.pem` key. Make sure you are on the **VPN / allowed networks** before connecting.

## Network & firewall

At the infrastructure level, **server-groups / security groups** define:

* Which internal subnets and services can reach:
  * MySQL (`3306`)
  * Redis (`6379`)
  * MongoDB (`27017`)
  * HAProxy frontends (TCP/HTTP ports)
  * Consul (`8300+` range)
* Which management networks can SSH into `cluster-n03` / `cluster-n04`.

Details of those rules live in the infrastructure-as-code / firewall configuration, not on the nodes themselves.

## Allowing a new IP in server-groups (SSH access)

Server access is managed on `cluster-n03` using **server-groups files** under the root home:

* Base path on `cluster-n03`:

  ```bash theme={null}
  sudo su -
  cd /root/server-groups
  ls
  ```

* Example files:
  * `cluster.servers`
  * `office.servers`
  * `pinpoint.servers`
  * etc.

Each `*.servers` file is a simple list of IP addresses, one per line. For example, `cluster.servers`:

```bash theme={null}
94.130.9.54
94.130.9.47
94.130.88.29
65.21.2.146
```

### Add a new IP using the scripts

There is a helper script `/root/iptables.sh` that:

* Enables and configures **UFW**.
* Opens base ports for:
  * SSH
  * HTTP / HTTPS
  * MySQL (`3306`)
* Iterates over all `server-groups/*.servers` files and:
  * Adds `ufw allow from <IP>` rules for each IP, tagged with a **RUN\_ID**.
* Removes any **old UFW rules** that do not match the current RUN\_ID.

Typical workflow:

```bash theme={null}
ssh cluster-n03
sudo su -
cd /root/server-groups
echo "NEW_IP_HERE" >> cluster.servers
cd ..
./iptables.sh
```

This:

* Appends the new IP to the `cluster.servers` list.
* Re-applies firewall rules for **all** server-groups via the script.

### Add a new IP manually (without running the full script)

If you **do not** want to run the full `.sh` script (e.g. you only want to affect one group):

1. **Edit the group file**:

   ```bash theme={null}
   ssh cluster-n03
   sudo su -
   cd /root/server-groups
   nano cluster.servers   # or your editor of choice
   ```

   * Add the new IP on its own line.
   * Save and exit.

2. **Apply firewall changes only for that IP/group**:

   * Follow the logic from `/root/iptables.sh` and run the specific `ufw allow from <IP>` commands manually for that IP/group.
   * This avoids re-running the entire script over all groups and rewriting all rules.

> When in doubt, prefer using the existing script and review it first, so manual changes stay consistent with the established firewall model.