Database failover and high availability for Drupal

Every Drupal page depends on the database. The web servers can be spread across several machines and zones, but if the single database behind them goes down, the whole site goes down with it. High availability for the database is about making that failure brief and automatic: a standby takes over within a couple of minutes, the application reconnects, and nobody has to be woken up to flip a switch.

What happens when a database fails

Without high availability, a failed database server means restoring from backup onto new hardware. That takes hours, and anything written since the last backup may be lost. With a standby in place, the timeline looks very different.

How Multi-AZ failover works

In a Multi-AZ setup, the primary database runs in one availability zone (a separate data center) and a standby runs in another. Every write is copied to the standby before it is confirmed, so the standby is always current. The application connects through a single endpoint name, not a server address.

When the primary fails, or when maintenance requires it, the platform promotes the standby and points the endpoint name at it. On managed services such as Amazon RDS and Aurora, this typically completes in one to two minutes. Azure Database for MySQL Flexible Server offers a similar zone-redundant option. No data that was confirmed as written is lost.

Standby versus read replica

They are complementary. A busy, important site often has both.

Making sure Drupal recovers on its own

The database recovering is only half the story. The application has to reconnect cleanly:

• Connect by endpoint name, never by IP address, in settings.php, so failover is followed automatically.
• Keep DNS caching short on the web servers, so they pick up the new address promptly.
• Expect a burst of errors during the minute or two of failover. Requests in flight will fail, and a friendly maintenance page served by the CDN is far better than a raw PHP error.
• Check long-running processes. Queue workers and scheduled jobs that hold a database connection need to reconnect or restart after failover.
• Keep the cache warm. With Redis or Memcached in front, many requests continue to be served from cache during the switch.

Test it before you need it

Managed database services let you trigger a failover deliberately. Doing so in a quiet window, first on a non-production environment and then on production, answers the real questions: how long did the site show errors, did everything reconnect, did scheduled jobs recover, did alerts fire? A failover path that has never been exercised is an assumption, not a plan.

Beyond one region

Multi-AZ protects against the failure of a server or a data center. It does not protect against a problem affecting a whole cloud region, or against bad data, such as an accidental mass deletion, which is faithfully copied to the standby. Those need backups with point-in-time recovery and, for critical sites, a cross-region recovery pattern such as a warm standby. The right level depends on how long the site can be down and how much data it can afford to lose, which is a business decision as much as a technical one.

A quick resilience checklist

1. Is the production database Multi-AZ or zone-redundant?
2. Does settings.php use the endpoint name?
3. Has a failover been tested, and when?
4. Is point-in-time recovery enabled, and has a restore been tested?
5. Do queue workers and cron recover after a failover?
6. Is there a clear recovery target for a regional outage?

Maintenance matters too. Managed databases apply some updates by failing over to the standby, patching the old primary, and switching back. Scheduling that maintenance window in a quiet period means the brief interruption lands when almost nobody is using the site.

How eWay runs Drupal databases

eWay runs production Drupal databases on managed services with Multi-AZ or zone-redundant configuration, automated backups, and point-in-time recovery. Applications connect through endpoint names, background workers are set up to reconnect, and failover is tested rather than assumed. eWay monitors connections, replication, storage growth, and backup success, and designs cross-region recovery for sites whose importance calls for it, against targets defined in your service agreement.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• Database connection errors seen, with times
• Whether the whole site or only some features were affected

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: database performance and read replicas and structuring Drupal environments. More on our Drupal page.