Jak osiągnąć wysoką dostępność w PostgreSQL?

Question

Accepted Answer

**Wysoka dostępność (HA)** oznacza utrzymanie dostępności bazy danych nawet w przypadku awarii — poprzez **replikację** (repliki rezerwowe), **automatyczne przejście w tryb failover** (promocja repliki gdy podstawowa ulega awarii) oraz odpowiednią architekturę. Cel: minimalizacja przestojów i utraty danych, ponieważ awarie bazy danych wyłączają całą aplikację.

## Fundamenty: replikacja + automatyczne failover

```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.
```

Replikacja utrzymuje repliki rezerwowe zsynchronizowane; **automatyczne failover** wykrywa awarię podstawowej i promuje replikę — zamieniając całkowitą awarię w krótką przerwę.

## Narzędzia HA (automatyzacja failover)

```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.
```

Manualny failover jest powolny i podatny na błędy, więc narzędzia HA (lub usługi zarządzane) automatyzują to bezpiecznie — w tym zapobieganie **split-brain** (dwie podstawowe akceptujące zapisy, co powoduje uszkodzenie danych).

## Routing połączeń

```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
```

## Kluczowe zagadnienia HA

```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.
```

## Dlaczego to ważne

Wysoka dostępność jest ważną wiedzą do operowania **krytycznymi dla produkcji** systemami PostgreSQL, ponieważ awarie bazy danych wyłączają całą aplikację (baza danych jest często najkrytyczniejszą zależnością), więc zrozumienie sposobów utrzymania dostępności Postgres-a mimo awarii jest cenną wiedzą na poziomie senior dla niezawodnych systemów.

Fundament — **replikacja plus automatyczne failover** — to to, co zamienia awarię głównej bazy danych (która w przeciwnym razie spowodowałaby całkowitą awarię aplikacji) w krótką, odwracalną przerwę: repliki rezerwowe pozostają zsynchronizowane, a gdy podstawowa ulega awarii, replika jest automatycznie promowana.

Zrozumienie **narzędzi HA** (Patroni — popularne rozwiązanie koordynujące failover poprzez magazyn konsensusu; repmgr; lub zarządzane PostgreSQL w chmurze z wbudowaną HA) jest ważne, ponieważ automatyzacja failover w bezpieczny sposób jest trudna do wykonania ręcznie.

Znajomość **kluczowych zagadnień** jest krytyczna: **replikacja synchroniczna** dla braku utraty danych podczas failover, **wiele replik w strefach dostępności** do przetrwania awarii strefy, a zwłaszcza **unikanie split-brain** (zapobieganie jednoczesnym zapisom w dwóch podstawowych, co powoduje uszkodzenie danych — poważne ryzyko, któremu zapobiegają konsensus/ogrodzenia).

Zrozumienie **routingu połączeń** (kierowanie aplikacji do bieżącej podstawowej po failover, poprzez load balancery/proxy) i że failover (jak kopie zapasowe) powinny być **testowane** uzupełnia praktyczną wiedzę.

Wiedza, że wiele zespołów używa **zarządzanego PostgreSQL** do sprawdzonej w praktyce HA jest również istotna.

Ponieważ dostępność bazy danych jest krytyczna dla systemów produkcyjnych (awaria wyłącza wszystko), a jej osiągnięcie wymaga zrozumienia replikacji, automatycznego failover, zapobiegania split-brain oraz routingu połączeń (lub użycia zarządzanego HA), zrozumienie wysokiej dostępności PostgreSQL jest ważną wiedzą na poziomie senior do architektowania niezawodnych, odpornych systemów — często krytyczne zagadnienie dla produkcyjnych baz danych i temat wykazujący zrozumienie budowania infrastruktury bazy danych, która przetrwa awarie, oczekiwane dla ról senior bazy danych/infrastruktury.