I’ve been working on a new plugin, this time it’s in the realm of real-time database replication, without needing to set up any additional accounts or worry about losing data during an extended downtime, or the space in between backups. I started this project wanting a simple, reliable failover plan for a WordPress e-commerce site.

It’s called ShadowDB and it works like a nearline replication shim. I’m running it currently, testing it on this blog post, and as I write and save drafts I’m monitoring the output as it writes to the secondary failover WordPress installation on another server.

The goal wasn’t to create a full high-availability cluster or a perfect mirror — just a practical backup environment on a second server that could take over quickly if the main server went down. We can’t exactly test it in real time, without changing our hosts file, but we do have a comparison section to know where there may be differences. If we start with a 1:1 clone of the site using Updraft, then we can easily move forward with both servers.

The first idea on the table was MySQL/MariaDB replication. It’s a standard solution – on paper – but it came with several problems for our setup. The hosting environment (WHM/cPanel) doesn’t support replication cleanly, and modifying the underlying MySQL configuration across multiple shared services wasn’t realistic. Replication also introduces risk: if something corrupts the primary database, it will happily replicate that corruption to the secondary. For a simple fallback server, replication was turning into more trouble than it was worth.

The next question was how “real-time” the failover needed to be. The WordPress files (plugins, themes, uploads) don’t change very often, so they don’t need continuous syncing. A nightly offsite backup using something like Updraft is perfectly acceptable, and what we typically use for site-level backups, on top of the WHM server-level backups to our storage server. The real risk is database content: orders, customers, posts, and settings. That data changes constantly and needs to be as fresh as possible on the secondary server.

That led to a different approach: a delayed, one-way write system. Instead of trying to keep two databases in constant lockstep, the idea is simple:

  • The primary database handles all normal reads and writes.
  • Every write query gets copied and sent to a secondary database.
  • The secondary database is “close enough” to real-time for failover purposes.
  • If the primary ever goes down, we can use Cloudflare to flip DNS to the secondary server.
  • It’s a one-way sync, so no opportunity to introduce corruption or out of sync changes.

This avoids the complexity of native MySQL replication while still giving us a reasonably current backup database. Because the write operation to the secondary isn’t blocking the main request, a temporary network hiccup can’t break the primary site. At worst, a few queries get queued and replayed later.

Yes, it DOES handle updates too, so any changes to existing rows will automatically get sent to the mirror DB too.

In this scenario, files don’t need continuous syncing (typically, and if they do, then we’d go a different route), DNS failover is handled externally through Cloudflare, and the database keeps itself updated through a lightweight plugin. That plugin tracks write operations, pushes them to the secondary server, and even provides admin tools to compare tables, resync differences, and monitor write delays.

The end result is a failover system built specifically for WordPress and shared hosting realities: simple to deploy, inexpensive to run, and without the operational overhead of full database replication. You could buy a cheap shared hosting plan and set this up for an emergency, and essentially “set it and forget it”. If you were to use a CDN offloading plugin, such as one that sends your images to Amazon s3, you’d probably not even notice that you were using a backup server.

Next on the list is automating the db.php installation, practical setup instructions (which would include adding the IP address of the main server to the secondary server), a guide on cloning your site using hosts to access the secondary server, and definitely some more testing.