Understanding Nginx Master‑Slave HA Architecture (Full Text and Diagrams)

Strictly speaking, Nginx does not offer database‑style master‑slave replication; the phrase usually describes a high‑availability architecture where a master Nginx handles traffic and a backup takes over when the master fails.

The architecture can be divided into four layers:

Access layer: a public VIP or domain name that clients use.

Master Nginx: performs request forwarding, SSL termination, routing, and rate limiting.

Backup Nginx: stays on standby, monitors the master’s health, and can assume traffic.

Backend service layer: the actual business service cluster.

When the master Nginx experiences an outage, Keepalived moves the VIP to the backup Nginx, allowing clients to continue without changing the address.

Typical configuration (simplified):

upstream backend_pool {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen 80;
    server_name app.example.com;
    location / {
        proxy_pass http://backend_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

The failover workflow is:

Under normal conditions the VIP points to Nginx‑A (master) and all requests are processed by it.

The master periodically synchronizes its configuration to the backup node.

If Nginx‑A crashes or its process stops, Keepalived detects the heartbeat loss.

The VIP automatically shifts to Nginx‑B (backup), which immediately takes over traffic.

After Nginx‑A recovers, its configuration is resynchronized and it returns to standby mode.