Database High Availability

Database high availability ensures that a database remains accessible despite hardware failures, network partitions, or planned maintenance. It uses replication, failover, clustering, and load distribution so that applications experience minimal or zero downtime.

itDatabases and data storage

Don't Panic — Database High Availability

Database high availability is the art of keeping a database service useful when some part of its supporting machinery has gone sideways. The reassuring diagram has a primary and several standbys. The less reassuring reality also has routers, connection pools, voting members, timeouts, and an application waiting to find out whether that last commit happened. The diagram omitted those because diagrams are kind.

Begin with the two labels that keep arguments from escaping into the ceiling. Recovery time objective, or RTO, is how long the resource may be unavailable. Recovery point objective, or RPO, is how far back its data may return after an outage. One governs detection, promotion, routing, and reconnection. The other governs which replication and commit guarantee is acceptable. A design with no stated objectives is not flexible. It is waiting for a surprise to choose them.

The central trick is that copies need permission. Replication moves changes from the writer to standby servers, but a network partition can leave healthy machines unable to talk. Quorum, the voting set allowed to decide, keeps the minority from inventing its own writable future. This feels rude when the minority has perfectly good hardware and urgent opinions. It is still kinder than producing two histories and asking someone to merge them after lunch.

Failover is therefore a controlled change of authority, not a magic button. Detect the failure, confirm the decision is safe, fence the old primary so it cannot accept writes, select a suitable standby, promote it, move routing, and let clients reconnect. Miss the routing step and the new primary has achieved an impressive private victory. Miss fencing and the old primary may keep writing somewhere you cannot see.

The surprising part is that a healthy standby does not prove availability. Existing connections can break, pools can retain stale sockets, and a dropped commit response leaves an unknown outcome. Retries need limits and an operation must be safe to repeat or identifiable enough to check. The database cannot decide whether charging an order twice was a clever recovery strategy.

Replication also is not a time machine. Asynchronous replicas can be behind, and a bad update can reach every current copy. Backups preserve older recovery points. Read the intro for the full service path and failure model, the slides for the sequence and tradeoffs, and the cheatsheet for quorum arithmetic, signals, and tests. Then test a switchover, a failure, and a restore. That is where an availability claim stops being decorative.

Don't Panic — Database High Availability

Relevant careers