Stop 06 · Database ServicesTopics · 3/10

Database Replication & High Availability

In short

Servers fail, and sometimes a whole data centre has a bad day. If your only database lives there, your app is down too. High availability means a standby is already waiting to take over.

Automatically maintaining synchronized copies of your database across zones or regions — Multi-AZ deployments provide automatic failover if the primary database instance fails.

The blob character in costume peeks out from behind a stage curtain, ready to go on.

Think of it like this

The understudy backstage

In the annual-day play, an understudy learns every line and waits in costume backstage. If the lead falls sick mid-show, the understudy walks on and the play continues. A Multi-AZ standby is that understudy for your database.

Watch it happen

A Multi-AZ failover

App

DB endpoint

Primary (AZ-a)

Standby (AZ-b)

INSERT order

1/6The app writes through the endpoint name, which points to the primary in zone A.

The big ideas

What you need to know

Synchronous standby

Multi-AZ keeps a standby in another zone, updated before each commit returns. It's for survival, not for reading.

Automatic failover

On failure or patching, the endpoint moves to the standby. Your connection string doesn't change.

Apps must reconnect

Connections drop during failover. Use retries with backoff and connection pools that recover cleanly.

Cross-region is different

Copies in another region are usually asynchronous, for disaster recovery. They can lag and may miss the last few seconds.

See it in code

Walk through the code

bash

1# Turn on Multi-AZ for an existing instance2aws rds modify-db-instance \3  --db-instance-identifier notes-db \4  --multi-az \5  --apply-immediately6 7# Practise a failover in a test environment8aws rds reboot-db-instance \9  --db-instance-identifier notes-db \10  --force-failover

1/2Add a standby in another zone. This costs roughly double the instance price.

Forcing a failover is the honest test of whether your app's retry logic really works. Do it in staging, not on a Friday in production.

Save yourself the pain

Common mistakes

Oops

Hard-coding the primary's IP address in the app.

Do this instead

Always connect via the endpoint name. After failover the IP changes, but the name follows the new primary.

Oops

Thinking Multi-AZ also protects against bad deletes.

Do this instead

The standby copies every change, including mistakes. You still need backups for that.

Your mission

Time a failover

~45 min

Quick check

Why is the Multi-AZ standby updated synchronously?

Go deeper

1Enable a Multi-AZ (or equivalent) deployment on a sample managed database.
2Learn the difference between synchronous replication (for HA) and asynchronous (often for read replicas).
3Understand the trade-off between replication cost and the downtime risk it protects against.