Hogyan lehet magas rendelkezésre állást (HA) elérni a PostgreSQL-ben?

Question

Accepted Answer

**A magas rendelkezésre állás (HA)** azt jelenti, hogy az adatbázis továbbra is elérhető marad, még akkor is, ha hibák lépnek fel — **replikáción** keresztül (standby replikák), **automatikus feladatátvételen** keresztül (replika előléptetése, amikor az elsődleges meghibásodik), és megfelelő architektúrán keresztül. A cél: minimalizálni az állásidőt és az adatvesztést, mivel az adatbázis-kimaradások az egész alkalmazást működésképtelenné teszik.

## Az alap: replikáció + automatikus feladatátvétel

```text
Primary ──(streaming replication)──▶ Standby replica(s)

If the PRIMARY fails:
  → a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
  → the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
```

A replikáció a standby replika példányokat szinkronban tartja; az **automatikus feladatátvétel** felismeri az elsődleges meghibásodást, és előléptet egy replikát — így egy teljes kimaradásból egy rövid szünet lesz.

## HA eszközök (feladatátvétel automatizálása)

```text
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
  Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
```

A manuális feladatátvétel lassú és hibára hajlamos, ezért a HA eszközök (vagy felügyelt szolgáltatások) biztonságosan automatizálják — beleértve a **split-brain** megelőzését (két elsődleges írásokat fogad, ami adatkorrupciót okoz).

## Kapcsolatirányítás

```text
Applications need to find the CURRENT primary after a failover:
  → a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
    WRITES to the current primary and READS to replicas
  → after failover, routing updates to point to the new primary
```

## A HA fő szempontjai

```text
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
```

## Miért fontos

A magas rendelkezésre állás fontos ismeret a **termelésben működő** PostgreSQL rendszerek üzemeltetéséhez, mivel az adatbázis-kimaradások az egész alkalmazást ledöntik (az adatbázis gyakran a legrészesebb kritikus függőség), ezért a Postgres elérhetőségének fenntartása a hibák ellenére is értékes senior szintű ismeret a megbízható rendszerekhez.

Az alap — **replikáció plusz automatikus feladatátvétel** — az, ami az elsődleges adatbázis meghibásodásából (amely egyébként teljes alkalmazás-kimaradást jelentene) egy rövid, helyreállítható szünetet csinál: a standby replikák szinkronban maradnak, és amikor az elsődleges meghibásodik, egy replika automatikusan előléptethető az átvételre.

Az **HA eszközöket** megérteni (Patroni — a népszerű megoldás, amely feladatátvételt koordinál egy konszenzus táron keresztül; repmgr; vagy felügyelt felhő PostgreSQL beépített HA-val) fontos, mert a feladatátvétel biztonságos automatizálása nehéz kézzel.

A **fő szempontok** ismerete kritikus: **szinkron replikáció** a feladatátvételkor adatvesztés nélkül, **több replika a rendelkezésre állási zónákon keresztül** a zóna-meghibásodások túléléséhez, és különösen a **split-brain elkerülése** (az két elsődleges egyidejűleg írást fogadásának megelőzése, ami adatkorrupciót okoz — egy súlyos kockázat, amelyet konszenzus/fencing megelőz).

A **kapcsolatirányítást** megérteni (az alkalmazást az aktuális elsődlegeshez irányítva a feladatátvétel után, terheléselosztók/proxyk használatán keresztül) és azt, hogy a feladatátvételt (mint a biztonsági mentéseket) **tesztelni** kell, lezárja a gyakorlati ismereteket.

Annak ismerete, hogy sok csapat **felügyelt PostgreSQL-t** használ a harci-tesztelt HA-hoz, szintén releváns.

Mivel az adatbázis rendelkezésre állása kritikus a termelési rendszereknél (egy kimaradás mindent ledönt), és mivel ezt replikáció, automatikus feladatátvétel, split-brain megelőzés és kapcsolatirányítás megértésével (vagy felügyelt HA használatával) lehet elérni, a PostgreSQL magas rendelkezésre állás megértése fontos senior szintű ismeret a megbízható, rugalmas rendszerek tervezéséhez — egy gyakran-kritikus szempont az üzemanyag adatbázisokhoz és egy olyan téma, amely a hibatűrő adatbázis infrastruktúra felépítésének megértésére utal, amelyet senior adatbázis-/infrastruktúra szerepkörökhöz várnak.