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 | OpenSkills.info
Intro
Database High Availability
Database high availability keeps a database service usable when part of its supporting system fails. It combines redundant data copies, failure detection, controlled role changes, and client routing.
No design removes every outage. Your job is to define the failures the service must survive, then prove the design meets that target.
This course gives you a practical map. You will learn how replication, quorum, failover, routing, durability, and recovery objectives fit together.
Start with the service objective
Availability belongs to the whole service, not one database process. A healthy standby does not help if applications cannot find it after failover.
Define the outcome before choosing a topology:
- Recovery time objective (RTO): the maximum acceptable time a system resource can remain unavailable.
- Recovery point objective (RPO): the point in time to which data must be recovered after an outage. An RTO shapes detection, election, promotion, routing, and application recovery. An RPO shapes replication and commit choices.
Ask which failures count. A design that survives one host failure may still fail when a rack, network zone, region, identity system, or router fails.
Build one service from several roles
A common topology has one read-write primary and one or more standby servers. The primary records changes. Replication carries those changes to each standby.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf
Supports
- Recovery point objective and recovery time objective definitions
- Business impact analysis, recovery priorities, contingency procedures, testing, and plan maintenance
- https://www.postgresql.org/docs/current/high-availability.html
Supports
- High availability and load-balancing purposes
- Primary, standby, warm standby, and hot standby terminology
- Synchronous and asynchronous replication behavior, data risk, consistency, and performance tradeoffs
- https://www.postgresql.org/docs/current/warm-standby.html
Supports
- Log shipping, streaming replication, standby promotion, and failover behavior
- Replication position and lag monitoring
- Synchronous commit acknowledgment, latency, and durability behavior
- Replication slots, retained log pressure, and standby reinitialization risks
- https://dev.mysql.com/doc/refman/8.4/en/group-replication.html
Supports
- Group membership, single-primary and multi-primary modes, failure tolerance, and automatic primary election
- Group Replication requirements, limitations, monitoring, consistency, and recovery topics
- https://dev.mysql.com/doc/refman/8.4/en/group-replication-performance.html
Supports
- Failure detection, member expulsion, automatic rejoin, network partition, quorum loss, and stopped transaction processing
- Performance, workload, message-size, and administrator-intervention considerations
- https://dev.mysql.com/doc/refman/8.4/en/group-replication-failure-detection.html
Supports
- Distributed failure suspicion and coordinated member expulsion
- Majority agreement for transactions and membership-view changes
- Isolated members cannot establish a new group view without quorum
- https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-innodb-cluster.html
Supports
- InnoDB Cluster topology, Group Replication, built-in failover, and primary promotion
- MySQL Router integration and transparent routing to the new primary
- Cluster fencing and recovery topics
- https://dev.mysql.com/doc/mysql-router/8.4/en/mysql-router-general-metadata.html
Supports
- Router placement between applications and database members
- Topology and live-state discovery
- Closed connections after backend loss and reconnection through another online member
- https://www.mongodb.com/docs/manual/core/replica-set-elections/
Supports
- Majority voting, primary elections, member priority, election triggers, write interruption, and rollback exposure
- https://www.mongodb.com/docs/manual/core/replica-set-write-concern/
Supports
- Write acknowledgment counts, majority durable commit, timeout behavior, latency, and rollback-risk tradeoffs
- https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-principles.html
Supports
- Testing recovery procedures, simulating failure scenarios, validating recovery, and correcting failure paths
- Distributing components to avoid a shared point of failure and planning capacity from measured demand
- https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
Supports
- Bounded timeouts, retry side effects, idempotent operations, retry limits, and backoff behavior