Česky na konci článku.

Database availability is one of the most important responsibilities of a modern Database Administrator.

A database can be fast, secure and perfectly backed up, but if it is unavailable when the business needs it, the entire application may effectively be unavailable.

This is why Database High Availability (HA) has become a fundamental part of modern database architecture.

High availability is not simply about creating a database cluster.

It is about designing a system that can continue operating when individual components fail.

For organizations running Oracle, PostgreSQL or MySQL, the exact implementation differs, but the underlying principles are remarkably similar.

What Is Database High Availability?

Database High Availability means designing a database service so that failures have as little impact as possible on users and applications.

A simple architecture might look like:

Application
|
Connection
Layer
|
┌───────┴───────┐
↓ ↓
Primary Standby
Database Database
|
└──── Replication ────→

If the primary database fails, the standby can potentially take over.

But a real HA architecture needs to consider much more than database replication.

1. Start With the Business Requirement

Not every database requires the same level of availability.

Before designing an HA solution, ask:

  • How much downtime is acceptable?
  • How much data loss is acceptable?
  • How quickly must failover occur?
  • Can the application reconnect automatically?
  • Is manual intervention acceptable?
  • What happens during a complete data-center failure?

For example:

Internal application

A few hours of downtime might be acceptable.

Business-critical application

Downtime of only a few minutes might be acceptable.

24/7 customer-facing platform

Even a short outage may have a significant financial impact.

The architecture must therefore be driven by business requirements, not by technology alone.

2. High Availability Is More Than Replication

One of the most common misconceptions is:

„We have replication, therefore we have high availability.“

Not necessarily.

Consider:

Application
↓
Load Balancer
↓
Database
↓
Storage

If the database fails but the application cannot connect to the new primary, the service is still unavailable.

A complete HA architecture must therefore consider:

  • database
  • operating system
  • storage
  • network
  • DNS
  • connection pooling
  • load balancing
  • monitoring
  • application behavior
  • failover automation

The goal is to protect the service, not just the database process.

3. Oracle High Availability

Oracle provides several technologies for building highly available environments.

Depending on requirements, a DBA may work with:

  • Oracle RAC
  • Data Guard
  • Active Data Guard
  • RAC One Node
  • RMAN
  • GoldenGate

These technologies solve different problems.

For example, Oracle RAC focuses on multiple database instances operating against shared database storage.

Data Guard provides physical or logical standby capabilities and is widely used for disaster recovery and database availability.

A senior Oracle DBA needs to understand not only how these technologies work, but also which problem each technology is actually solving.

4. PostgreSQL High Availability

PostgreSQL provides several building blocks for HA architectures.

Common technologies include:

  • streaming replication
  • physical replication
  • logical replication
  • Patroni
  • etcd
  • PgBouncer
  • PostgreSQL backups
  • WAL archiving

A typical PostgreSQL HA environment might look like:

Application
|
PgBouncer
|
┌──────┴──────┐
↓ ↓
PostgreSQL PostgreSQL
Primary Standby
|
└── Streaming
Replication

In more advanced environments, Patroni can manage PostgreSQL high availability and coordinate failover with a distributed configuration store such as etcd.

But HA is not created simply by installing Patroni.

The complete system must be designed, tested and monitored.

5. MySQL High Availability

MySQL also provides several HA options.

Depending on the environment, DBAs may use:

  • asynchronous replication
  • semi-synchronous replication
  • Group Replication
  • InnoDB Cluster
  • InnoDB ReplicaSet
  • MySQL Router

A simplified architecture could look like:

Application
|
MySQL Router
|
┌──────────┼──────────┐
↓ ↓ ↓
MySQL MySQL MySQL
Node 1 Node 2 Node 3

The architecture should be selected according to the required level of availability, consistency, performance and operational complexity.

6. Automatic Failover

The biggest advantage of a properly designed HA system is the ability to reduce manual intervention.

Without automatic failover:

Database Failure
↓
Alert
↓
DBA
↓
Investigation
↓
Manual Failover
↓
Application Recovery

With a properly designed automated solution:

Database Failure
↓
Detection
↓
Failover
↓
New Primary
↓
Application Reconnect

The second architecture can dramatically reduce recovery time.

However, automatic failover introduces its own risks.

A system must be able to distinguish between:

temporary connectivity problems

and

actual primary database failure.

7. Split-Brain Is One of the Most Dangerous HA Problems

Consider a cluster where two nodes both believe they are primary.

Node A
PRIMARY
↕
Network
↕
Node B
PRIMARY

Both nodes may accept writes.

Now the environment has a split-brain situation.

This can result in:

  • conflicting data
  • replication problems
  • data corruption
  • difficult recovery

This is why HA systems need mechanisms for quorum, fencing and leader election.

In distributed PostgreSQL architectures, technologies such as etcd can participate in leader coordination.

The important principle is:

A failed node must not be allowed to continue behaving as the active primary when another node has already taken over.

8. Monitoring Is Part of High Availability

You cannot operate an HA environment safely without monitoring.

Important metrics include:

  • replication lag
  • database health
  • node status
  • connection count
  • CPU
  • memory
  • storage latency
  • WAL generation
  • disk space
  • failover status
  • backup status

For PostgreSQL:

Primary
↓
WAL
↓
Replication
↓
Standby
↓
Replication Lag

Replication lag should be monitored continuously.

A standby that is several hours behind may technically be healthy, but it may not provide the recovery capability the business expects.

9. Backups Are Still Necessary

High availability does not replace backups.

This is one of the most important concepts in database administration.

Replication protects against some types of infrastructure failure.

It does not necessarily protect against:

  • accidental DELETE
  • incorrect UPDATE
  • application bugs
  • malicious activity
  • logical corruption

Imagine:

DELETE FROM customers;

If the transaction commits successfully, replication may faithfully copy the mistake to every replica.

Therefore:

HA protects availability.

Backups protect recoverability.

You need both.

10. Disaster Recovery Is Different From High Availability

High Availability usually focuses on relatively fast recovery from infrastructure or node failures.

Disaster Recovery focuses on larger events.

For example:

Server failure
↓
HA / Failover

versus:

Data center failure
↓
Disaster Recovery
↓
Secondary location

A robust architecture may therefore include:

Primary Data Center
↓
HA Cluster
↓
Replication
↓
Secondary Data Center
↓
DR Environment

The exact design depends on RPO, RTO and business requirements.

11. Test Failover — Don’t Assume It Works

One of the biggest mistakes in HA projects is never testing failover.

The architecture may look perfect on paper.

But during a real failure, something unexpected happens:

  • DNS does not update
  • application connections remain open
  • firewall rules block the new primary
  • replication is broken
  • monitoring does not detect the failure
  • automation fails
  • credentials are missing

The only way to discover these problems is to test.

A proper HA test should answer:

Can the application continue working after the primary database fails?

Not merely:

Did the standby become primary?

12. Planned and Unplanned Failover

There are two very different scenarios.

Planned failover

Used for:

  • maintenance
  • upgrades
  • infrastructure changes
  • testing

The DBA has time to prepare.

Unplanned failover

Used when:

  • server crashes
  • storage fails
  • network fails
  • database becomes unavailable

There may be no preparation time.

Both scenarios should be tested.

13. Application Connections Matter

A database can fail over successfully while the application continues trying to connect to the old primary.

This is why connection architecture is critical.

Applications may use:

  • DNS
  • virtual IP
  • load balancer
  • database proxy
  • connection pool
  • service discovery

The goal is:

Primary Failure
↓
New Primary
↓
Connection Layer
↓
Application

The application should not need to know the physical location of every database node.

14. Automation Reduces Recovery Time

Automation can make HA environments significantly more reliable.

For example:

Health Check
↓
Failure Detection
↓
Leader Election
↓
Failover
↓
Connection Redirect
↓
Monitoring
↓
Validation

Technologies such as Ansible can also help ensure that database nodes have consistent configuration.

This is especially valuable when operating multiple environments.

15. High Availability Creates Operational Complexity

HA is not free.

More nodes mean:

  • more configuration
  • more monitoring
  • more networking
  • more failure scenarios
  • more testing
  • more operational complexity

A three-node cluster is not automatically better than a single well-managed database.

The correct architecture is the simplest architecture that meets the required business objectives.

This is an important principle:

Do not build HA because the technology is interesting. Build it because the business requires it.

16. The Senior DBA Perspective

A junior administrator may ask:

„How do I configure replication?“

A senior DBA asks:

„What happens when replication stops?“

A junior DBA may ask:

„How do I configure failover?“

A senior DBA asks:

„What happens if failover occurs at the same time as a network partition?“

And an experienced Database Reliability Engineer asks:

„How will we detect the failure, recover automatically, validate the service and prevent the same incident from happening again?“

This difference in thinking is critical.

Practical HA Checklist

Before declaring a database highly available, verify:

Architecture

  • Primary and standby architecture defined
  • Failure scenarios documented
  • Network dependencies identified
  • Storage dependencies identified

Replication

  • Replication configured
  • Replication lag monitored
  • Recovery process tested

Failover

  • Automatic or manual failover defined
  • Split-brain protection implemented
  • Fencing / quorum strategy defined
  • Application reconnection tested

Backup

  • Backups running
  • Backups monitored
  • Restore tested
  • Point-in-time recovery tested

Disaster Recovery

  • DR environment defined
  • RPO documented
  • RTO documented
  • DR test performed

Operations

  • Monitoring configured
  • Alerting configured
  • Runbooks documented
  • Failover regularly tested

Final Takeaway

Database High Availability is not simply about having two database servers.

It is about creating a complete recovery mechanism for the database service.

Oracle, PostgreSQL and MySQL provide different technologies for implementing HA, but the fundamental principles remain the same:

Detect failure.

Prevent split-brain.

Promote a healthy node.

Reconnect the application.

Validate the service.

Recover the failed component.

And most importantly:

Test the entire process before a real production failure tests it for you.

The best HA architecture is not the one with the most servers.

It is the one where the business can continue operating when something inevitably fails.

About the Author

Tomas Solar
Principal Database Reliability Engineer

20+ years of experience with Oracle, PostgreSQL, MySQL, SQL Server and MongoDB.

Specialized in Database Administration, High Availability, Performance Engineering, Disaster Recovery, Database Reliability, Automation, Database Migration and Database Architecture.

High availability is not the absence of failure. It is the ability to continue operating when failure occurs.

Vysoká dostupnost databází: Jak navrhnout spolehlivé systémy pro Oracle, PostgreSQL a MySQL

Dostupnost databáze patří mezi nejdůležitější odpovědnosti moderního Database Administrátora.

Databáze může být rychlá, bezpečná a perfektně zálohovaná. Pokud ale není dostupná ve chvíli, kdy ji business potřebuje, může být prakticky nedostupná celá aplikace.

Proto se Database High Availability (HA) stala základní součástí moderní databázové architektury.

High Availability není pouze o vytvoření databázového clusteru.

Jde o návrh systému, který dokáže pokračovat v provozu i v případě selhání jednotlivých komponent.

U systémů založených na Oracle, PostgreSQL nebo MySQL se konkrétní technologie liší, ale základní principy jsou velmi podobné.

Co je Database High Availability?

Database High Availability znamená navrhnout databázovou službu tak, aby případné selhání mělo co nejmenší dopad na uživatele a aplikace.

Jednoduchá architektura může vypadat například takto:

Aplikace
|
Connection Layer
|
┌──────┴──────┐
↓ ↓
Primary Standby
Database Database
|
└──── Replikace ────→

Pokud primární databáze selže, standby databáze může převzít její roli.

Reálná HA architektura ale musí řešit mnohem více než pouze replikaci databáze.

1. Začněte business požadavky

Ne každá databáze potřebuje stejnou úroveň dostupnosti.

Před návrhem HA řešení je potřeba zjistit:

  • Jak dlouhý výpadek je přijatelný?
  • Jakou ztrátu dat lze akceptovat?
  • Jak rychle musí proběhnout failover?
  • Dokáže se aplikace automaticky znovu připojit?
  • Je přijatelný manuální zásah?
  • Co se stane při úplném výpadku datového centra?

Například:

Interní aplikace

Několik hodin odstávky může být přijatelné.

Kritická podniková aplikace

Přijatelný může být pouze několikaminutový výpadek.

Zákaznická 24/7 platforma

I krátký výpadek může mít významný finanční dopad.

Architektura proto musí vycházet z business požadavků, nikoliv pouze z dostupných technologií.

2. High Availability není pouze replikace

Jedna z nejčastějších představ je:

„Máme replikaci, takže máme High Availability.“

Nemusí to být pravda.

Představme si:

Aplikace
↓
Load Balancer
↓
Databáze
↓
Storage

Pokud databáze selže, ale aplikace se nedokáže připojit k novému primary serveru, služba je stále nedostupná.

Kompletní HA architektura proto musí řešit:

  • databázi
  • operační systém
  • storage
  • síť
  • DNS
  • connection pooling
  • load balancing
  • monitoring
  • chování aplikace
  • automatizaci failoveru

Cílem je chránit celou službu, ne pouze databázový proces.

3. High Availability v Oracle

Oracle poskytuje několik technologií pro vytváření vysoce dostupných prostředí.

Podle požadavků může DBA pracovat například s:

  • Oracle RAC
  • Data Guard
  • Active Data Guard
  • RAC One Node
  • RMAN
  • GoldenGate

Tyto technologie řeší různé problémy.

Například Oracle RAC umožňuje provoz více databázových instancí nad sdíleným databázovým úložištěm.

Data Guard poskytuje standby databázové prostředí a často se používá pro disaster recovery a vysokou dostupnost.

Seniorní Oracle DBA by měl rozumět nejen tomu, jak jednotlivé technologie fungují, ale především tomu, jaký problém každá z nich skutečně řeší.

4. High Availability v PostgreSQL

PostgreSQL poskytuje několik základních stavebních bloků pro HA architektury.

Mezi běžné technologie patří:

  • streaming replication
  • physical replication
  • logical replication
  • Patroni
  • etcd
  • PgBouncer
  • PostgreSQL backup
  • WAL archiving

Typické PostgreSQL HA prostředí může vypadat:

Aplikace
|
PgBouncer
|
┌──────┴──────┐
↓ ↓
PostgreSQL PostgreSQL
Primary Standby
|
└── Streaming
Replication

V pokročilejších prostředích může Patroni řídit vysokou dostupnost PostgreSQL a koordinovat failover pomocí distribuovaného konfiguračního úložiště, například etcd.

Samotná instalace Patroni ale automaticky neznamená, že máme vysoce dostupný systém.

Celé prostředí musí být správně navrženo, otestováno a monitorováno.

5. High Availability v MySQL

MySQL rovněž poskytuje několik možností pro HA.

Podle konkrétního prostředí může DBA použít:

  • asynchronous replication
  • semi-synchronous replication
  • Group Replication
  • InnoDB Cluster
  • InnoDB ReplicaSet
  • MySQL Router

Zjednodušená architektura může vypadat:

Aplikace
|
MySQL Router
|
┌─────────┼─────────┐
↓ ↓ ↓
MySQL MySQL MySQL
Node 1 Node 2 Node 3

Architekturu je potřeba vybrat podle požadavků na dostupnost, konzistenci, výkon a provozní složitost.

6. Automatický failover

Jednou z největších výhod správně navrženého HA systému je omezení manuálního zásahu.

Bez automatizace:

Výpadek databáze
↓
Alert
↓
DBA
↓
Analýza
↓
Manuální failover
↓
Obnova aplikace

S dobře navrženou automatizací:

Výpadek databáze
↓
Detekce
↓
Failover
↓
Nový Primary
↓
Reconnect aplikace

Druhá architektura může výrazně zkrátit dobu obnovy.

Automatický failover ale přináší také vlastní rizika.

Systém musí například správně rozlišit mezi:

dočasným problémem s konektivitou

a

skutečným výpadkem primary databáze.

7. Split-brain je jedno z největších rizik HA

Představme si cluster, ve kterém dva nody současně věří, že jsou primary:

Node A
PRIMARY
↕
Network
↕
Node B
PRIMARY

Oba nody mohou přijímat zápisy.

Vzniká situace známá jako split-brain.

Ta může způsobit:

  • konfliktní data
  • problémy s replikací
  • poškození dat
  • velmi složitou obnovu

Proto HA systémy potřebují mechanismy pro:

  • quorum
  • fencing
  • leader election

V distribuovaných PostgreSQL architekturách může při koordinaci leadera pomáhat například etcd.

Základní princip je:

Selhaný node nesmí pokračovat v chování jako aktivní primary, pokud již jiný node převzal jeho roli.

8. Monitoring je součástí High Availability

HA prostředí nelze bezpečně provozovat bez monitoringu.

Mezi důležité metriky patří:

  • replication lag
  • stav databáze
  • stav nodů
  • CPU
  • memory
  • storage latency
  • WAL generation
  • volné místo
  • stav failoveru
  • stav backupu

Například u PostgreSQL:

Primary
↓
WAL
↓
Replication
↓
Standby
↓
Replication Lag

Replication lag je potřeba sledovat průběžně.

Standby, která je několik hodin pozadu, může být technicky zdravá, ale nemusí poskytovat úroveň recovery, kterou business očekává.

9. Backup je stále nezbytný

High Availability nenahrazuje backup.

To je jeden z nejdůležitějších principů databázové administrace.

Replikace chrání proti některým typům infrastrukturních výpadků.

Nechrání ale nutně proti:

  • omylem provedenému DELETE
  • chybnému UPDATE
  • chybě aplikace
  • útoku
  • logickému poškození dat

Představme si:

DELETE FROM customers;

Pokud je transakce úspěšně potvrzena, replikace může tuto chybu věrně přenést na všechny repliky.

Proto:

HA chrání dostupnost.

Backup chrání obnovitelnost.

Potřebujete obojí.

10. Disaster Recovery je něco jiného než High Availability

High Availability se obvykle zaměřuje na rychlou obnovu po výpadku jednotlivých komponent nebo nodů.

Disaster Recovery řeší větší katastrofické události.

Například:

Výpadek serveru
↓
HA / Failover

oproti:

Výpadek datového centra
↓
Disaster Recovery
↓
Sekundární lokalita

Robustní architektura může vypadat například:

Primární datové centrum
↓
HA Cluster
↓
Replikace
↓
Sekundární datové centrum
↓
DR prostředí

Konkrétní návrh závisí na požadavcích na RPO, RTO a business kontinuitu.

11. Failover je potřeba testovat

Jednou z největších chyb při HA projektech je nikdy failover neotestovat.

Architektura může na papíře vypadat dokonale.

Při skutečném výpadku ale může nastat například:

  • DNS se nepřepne
  • aplikační connections zůstanou otevřené
  • firewall zablokuje nový primary
  • replikace není aktuální
  • monitoring výpadek nezachytí
  • automatizace selže
  • chybí potřebné credentials

Jediný způsob, jak tyto problémy objevit, je testování.

Správný HA test by měl odpovědět na otázku:

Dokáže aplikace pokračovat v provozu po výpadku primary databáze?

Ne pouze:

Stal se standby nový primary?

12. Plánovaný a neplánovaný failover

Existují dva velmi rozdílné scénáře.

Plánovaný failover

Používá se například při:

  • údržbě
  • upgradech
  • změnách infrastruktury
  • testování

DBA má čas se připravit.

Neplánovaný failover

Nastane například při:

  • pádu serveru
  • výpadku storage
  • výpadku sítě
  • nedostupnosti databáze

V takové situaci nemusí být čas na přípravu.

Oba scénáře by proto měly být pravidelně testovány.

13. Aplikační connections jsou velmi důležité

Databáze může failover úspěšně dokončit, ale aplikace se stále může pokoušet připojovat na původní primary.

Proto je connection architektura velmi důležitá.

Aplikace mohou používat:

  • DNS
  • virtual IP
  • load balancer
  • database proxy
  • connection pool
  • service discovery

Cílem je:

Výpadek Primary
↓
Nový Primary
↓
Connection Layer
↓
Aplikace

Aplikace by ideálně neměla znát fyzické umístění každého databázového nodu.

14. Automatizace zkracuje dobu obnovy

Automatizace může HA prostředí výrazně zvýšit spolehlivost.

Například:

Health Check
↓
Detekce výpadku
↓
Leader Election
↓
Failover
↓
Přesměrování connections
↓
Monitoring
↓
Validace

Technologie jako Ansible mohou zároveň pomoci zajistit konzistentní konfiguraci databázových nodů.

To je velmi užitečné zejména při provozu více prostředí.

15. High Availability přináší provozní složitost

HA není zadarmo.

Více nodů znamená:

  • více konfigurace
  • více monitoringu
  • více síťových závislostí
  • více scénářů selhání
  • více testování
  • větší provozní složitost

Tříuzlový cluster proto není automaticky lepší než jeden dobře spravovaný databázový server.

Správná architektura je nejjednodušší architektura, která splňuje požadavky businessu.

Důležitý princip tedy zní:

Nestavte HA proto, že je technologie zajímavá. Stavte ho proto, že ho business skutečně potřebuje.

16. Pohled Senior DBA

Junior administrátor se může ptát:

„Jak nakonfiguruji replikaci?“

Senior DBA se ptá:

„Co se stane, když se replikace zastaví?“

Junior DBA může řešit:

„Jak nastavím failover?“

Senior DBA se ptá:

„Co se stane, když failover nastane současně s výpadkem síťového spojení?“

A zkušený Database Reliability Engineer se ptá:

„Jak výpadek detekujeme, jak provedeme automatickou obnovu, jak ověříme službu a jak zabráníme opakování stejného incidentu?“

Právě tento způsob přemýšlení je zásadní.

Praktický HA checklist

Před označením databáze jako vysoce dostupné ověřte:

Architektura

  • Primary a standby architektura je definována
  • Jsou zdokumentovány scénáře selhání
  • Jsou identifikovány síťové závislosti
  • Jsou identifikovány storage závislosti

Replikace

  • Replikace je nakonfigurována
  • Replication lag je monitorován
  • Recovery proces je otestován

Failover

  • Je definován automatický nebo manuální failover
  • Je implementována ochrana proti split-brain
  • Je definována strategie fencing/quorum
  • Je otestováno znovupřipojení aplikace

Backup

  • Backup probíhá
  • Backup je monitorován
  • Restore byl otestován
  • Point-in-time recovery bylo otestováno

Disaster Recovery

  • DR prostředí je definováno
  • RPO je zdokumentováno
  • RTO je zdokumentováno
  • DR test byl proveden

Provoz

  • Monitoring je nakonfigurován
  • Alerting je nakonfigurován
  • Runbooky jsou zdokumentovány
  • Failover se pravidelně testuje

Závěr

Database High Availability není pouze o tom mít dva databázové servery.

Jde o vytvoření kompletního mechanismu obnovy celé databázové služby.

Oracle, PostgreSQL a MySQL nabízejí různé technologie pro implementaci HA, ale základní principy zůstávají stejné:

Detekovat výpadek.

Zabránit split-brain.

Povýšit zdravý node.

Znovu připojit aplikaci.

Ověřit službu.

Obnovit vadný komponent.

A především:

Otestujte celý proces dříve, než ho za vás otestuje skutečný produkční výpadek.

Nejlepší HA architektura není ta, která má nejvíce serverů.

Je to ta, ve které může business pokračovat v provozu i ve chvíli, kdy něco nevyhnutelně selže.

O autorovi

Tomas Solar
Principal Database Reliability Engineer

Více než 20 let zkušeností s Oracle, PostgreSQL, MySQL, SQL Server a MongoDB.

Specializace na Database Administration, High Availability, Performance Engineering, Disaster Recovery, Database Reliability, Automation, Database Migration a Database Architecture.

High Availability neznamená absenci výpadků. Znamená schopnost pokračovat v provozu, i když k výpadku dojde.



Komentáře