Database high availability is more than replication.

What database high availability means

Database high availability (HA) is the ability to keep a database-backed service accessible through server, storage, network, process and maintenance events. Availability is usually expressed as a service objective, but architecture teams also need to define the failure domains included in that objective.

A design that survives one database process crash may not survive a rack outage. A multi-zone cluster may not survive operator error or corrupted data. A multi-region topology may remain online while violating consistency requirements. High availability therefore has to be evaluated against concrete scenarios.

RTO, RPO and consistency targets

These targets interact. Synchronous replication can reduce RPO but adds commit latency and may reduce availability during communication failures. Asynchronous replication can improve local write latency but may lose recently acknowledged transactions. The correct tradeoff depends on business invariants.

Core HA components

Redundant database nodes

Redundancy removes a single server as the only copy or execution path. The replicas must be placed in independent failure domains and monitored for actual readiness, not merely process health.

Replication

Physical replication copies storage-level changes; logical replication copies row-level or transaction-level changes. Synchronous and asynchronous modes provide different latency and durability tradeoffs. Replication topology should match the failover and write-ownership model.

Health detection and fencing

Health checks must distinguish a slow node from a failed node and a network partition from a local outage. Fencing prevents an old primary from continuing to accept writes after a new primary is promoted.

Traffic routing

Applications need a stable endpoint, proxy, router, service discovery layer or connection policy that sends traffic to the correct node. Connection pools must refresh after topology changes.

Observability

Monitor replication lag, commit latency, error rates, queue depth, disk capacity, lock waits, node membership, backup age, restore tests and data-consistency signals. Alerts should map to operator actions.

Backups and point-in-time recovery

HA replicas protect service continuity but may replicate logical corruption. Independent backups, retention and verified restoration protect against accidental deletion, bad deployments, ransomware and prolonged corruption.

Common database HA patterns

Failure testing checklist

• terminate the active database process;
• disconnect one node from the network;
• simulate replication lag and disk exhaustion;
• restart or rebuild a failed node;
• promote and fail back without split-brain;
• verify application retry and idempotency behavior;
• restore a backup into an isolated environment;
• test schema changes while replicas are active;
• measure stale reads and lost acknowledged writes;
• reconcile data after a partial failure.

Runbooks should state who decides to fail over, what telemetry is required, how writes are fenced, how clients reconnect and how the old node is validated before rejoining.

HA and active-active architecture

Active-active is one possible HA strategy, but it should not be used as a synonym for availability. Multiple active nodes can reduce failover dependency and increase utilization, yet they also create more paths for conflicting writes or divergent state. Review the active-active database guide and the active-active versus active-passive comparison before selecting the model.

ShardronDB perspective

ShardronDB focuses on the control point before writes reach relational nodes. The public architecture discusses gateway validation, ownership-aware routing, generated primary keys, backup-table placement, monitoring and consistency checks. These mechanisms can contribute to HA, but they do not replace independent backups, network design, quorum decisions or recovery testing.

Use the architecture evaluation form to document your current model, node count and pain points without sending credentials or production data.

Frequently asked questions