Highly Available WordPress with Automatic Failover

This guide walks you through setting up a WordPress site that stays online even if a server or database fails. You’ll configure two web servers, a shared database, and a floating IP that automatically moves to the healthy server. By the end, you’ll have a basic active-passive setup that detects failures and switches traffic in seconds.

What You’ll Need

Two Linux servers (Ubuntu 22.04 or 24.04 recommended) with root or sudo access.
A third server for the database (or use a managed database service like Amazon RDS, DigitalOcean Managed Database, etc.).
A floating IP or elastic IP from your cloud provider (or a way to script DNS updates).
Basic familiarity with the command line, SSH, and WordPress installation.
Optional: A domain name pointed to the floating IP.

Step-by-Step

Set up the database server

Install MySQL or MariaDB on the dedicated database server. Create a WordPress database and a user with privileges on that database. For example:
```
CREATE DATABASE wordpress;
CREATE USER 'wpuser'@'%' IDENTIFIED BY 'strongpassword';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'%';
FLUSH PRIVILEGES;
```
Bind MySQL to the private network interface (not 127.0.0.1) so both web servers can reach it. Edit /etc/mysql/mysql.conf.d/mysqld.cnf and set bind-address = 0.0.0.0 (or your private IP). Restart MySQL.
Install WordPress on the first web server

Install Apache or Nginx, PHP, and the required PHP extensions on the first web server. Download WordPress, extract it to the web root, and configure wp-config.php with the database host (the database server’s private IP), database name, username, and password. Set WP_HOME and WP_SITEURL to your domain or floating IP.
Copy WordPress to the second web server

Install the same web server software and PHP on the second server. Copy the entire WordPress directory from the first server to the second using rsync or scp. Also copy the wp-config.php file. Ensure the file permissions are correct (usually 644 for files, 755 for directories).
Share the WordPress uploads directory

To keep media files in sync, use a shared storage solution like NFS, or a cloud object store with a plugin (e.g., S3 offload). A simple NFS setup: on the database server or a separate storage server, export the wp-content/uploads directory. Mount it on both web servers at the same path. This ensures that images uploaded on one server appear on the other.
Configure the floating IP

In your cloud provider’s control panel, create a floating IP and assign it to the first web server. Note the floating IP address. This IP will be the single address that clients use to reach your site.
Install and configure Keepalived on both web servers

Install keepalived on both servers. Create a configuration file /etc/keepalived/keepalived.conf on each server. The first server (primary) should have a higher priority (e.g., 100) and the second (backup) a lower priority (e.g., 50). Both should use the same virtual IP (the floating IP). A minimal config:
```
vrrp_instance VI_1 {
    state MASTER  # on backup: BACKUP
    interface eth0
    virtual_router_id 51
    priority 100   # on backup: 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret123
    }
    virtual_ipaddress {
        203.0.113.10/24  # your floating IP
    }
}
```
Replace eth0 with your network interface name. Restart keepalived on both servers. The floating IP will now be active on the primary server.
Test failover manually

From your local machine, ping the floating IP. Then stop keepalived on the primary server (sudo systemctl stop keepalived). Within a few seconds, the backup server should take over the IP. Ping again to confirm it still responds. Start keepalived on the primary again to verify it reclaims the IP.
Add health checks to keepalived

Keepalived can monitor a service and fail over if it goes down. Add a script that checks if Apache/Nginx is running. For example, create /etc/keepalived/check_web.sh:
```
#!/bin/bash
if systemctl is-active --quiet nginx; then
    exit 0
else
    exit 1
fi
```
Make it executable and reference it in the keepalived config with track_script:
```
track_script {
    chk_web {
        script "/etc/keepalived/check_web.sh"
        interval 2
        fall 2
        rise 2
    }
}
```
This will trigger failover if the web server service stops.
Handle database failover

For full high availability, you also need database redundancy. Set up MySQL replication between two database servers (or use a managed service with automatic failover). Keepalived can also manage the database IP, but a simpler approach is to use a database proxy like ProxySQL or a managed service. If you use a managed database, the provider handles failover automatically; just point both web servers to that endpoint.
Update WordPress configuration for failover

In wp-config.php, add the following to allow WordPress to work behind a floating IP and to handle HTTPS if needed:
```
define('WP_HOME', 'http://yourdomain.com');
define('WP_SITEURL', 'http://yourdomain.com');
$_SERVER['HTTP_HOST'] = 'yourdomain.com';
```
Also, ensure that the database host is the same on both servers (the database server’s IP or hostname).
Final test: simulate a server failure

Upload a test file to the primary server’s web root. Then power off the primary server entirely. Wait a few seconds and access the floating IP in a browser. You should see the same WordPress site, served by the backup server. Also test uploading an image to ensure the shared uploads directory works.

Common Mistakes

Not sharing uploads: If you forget to sync wp-content/uploads, images will disappear or break after failover.
Hardcoding server IPs in WordPress: If you use the server’s IP in wp-config.php or the database host, it may break when the IP moves. Always use the floating IP or a hostname.
Ignoring database replication: If the database goes down, your site will fail even if web servers are healthy. Ensure the database is also highly available.
Misconfigured keepalived authentication: Keepalived instances must use the same password and virtual_router_id, or they won’t communicate.
Firewall blocking VRRP: Keepalived uses VRRP (protocol 112). Make sure your firewall allows it between the two web servers.

Tips

Use a managed database service (like RDS, Cloud SQL) to avoid running your own replication. It simplifies failover significantly.
Monitor both servers with a tool like UptimeRobot or a self-hosted uptime monitor to get alerts when failover occurs.
Test failover regularly (e.g., monthly) to ensure the system works when you need it.
Use version control for your theme and plugins so you can redeploy quickly if a server is lost.
Consider using a load balancer instead of a floating IP if you need to scale to more than two servers. The same keepalived concept can apply, but a cloud load balancer is easier to manage.

Troubleshooting

Floating IP doesn’t move after failover: Check keepalived logs (journalctl -u keepalived). Ensure the backup server’s config has the same virtual_router_id and authentication. Also verify the interface name is correct.
WordPress shows database connection error after failover: The database server may be down. If you’re using a single DB, you need to set up replication. If using a managed service, check that the endpoint is reachable from the backup server.
Images missing after failover: Check that the shared uploads directory is mounted on the backup server and that permissions allow the web server to read it.
Site loads but with broken styles: This often happens because the site URL in the database is still the old server IP. Run wp search-replace 'http://old-ip' 'http://new-domain' --all-tables with WP-CLI, or update the siteurl and home options in the database.
Keepalived fails to start: Check the config file syntax with keepalived -t -f /etc/keepalived/keepalived.conf. Common issues are missing commas or incorrect indentation.

Frequently Asked Questions

Do I need two web servers for high availability?

Yes, at least two. One is active, the other stands by. If the active fails, the standby takes over.

Can I use a domain name instead of a floating IP?

Yes, you can point your domain to the floating IP. That way, visitors use the domain, and the IP can change without affecting them.

What if my cloud provider doesn’t offer floating IPs?

You can use a dynamic DNS service or a script that updates the DNS A record when failover occurs. Keepalived can trigger such a script via its notify scripts.

Is this setup truly automatic?

Yes, keepalived detects the failure and moves the IP automatically within seconds. The only manual part is the initial setup.

Do I need to replicate the entire WordPress directory?

You need the core files, themes, and plugins. The uploads directory should be shared or replicated separately. You can use rsync to sync the files periodically, or use a shared filesystem.

How do I handle WordPress updates in this setup?

Update one server, test, then copy the changes to the other. For the database, run updates on the primary DB and let replication handle the secondary.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →