Jak działa replikacja w PostgreSQL?

Question

Accepted Answer

**Replikacja** kopiuje dane z bazy danych **głównej** (primary) do jednego lub więcej serwerów **repliki** (standby) — dla wysokiej dostępności (failover w przypadku awarii primaru) i skalowania odczytów (rozprowadzenie zapytań odczytu). PostgreSQL głównie używa **replikacji strumieniowej** (physical) opartej na logu Write-Ahead Log (WAL).

## Streaming (physical) replication

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

Serwer główny strumieniuje swój **WAL** (write-ahead log — zapis każdej zmiany) do replik, które go stosują, aby pozostać zsynchronizowane. Repliki to kopie tylko do odczytu, które mogą obsługiwać zapytania odczytu.

## Korzyści: HA i skalowanie odczytów

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Replikacja synchroniczna vs asynchroniczna

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Logical replication (inny model)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## Wysoka dostępność w praktyce

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## Dlaczego to ważne

Replikacja jest istotna do budowania **wysoce dostępnych i skalowalnych** wdrożeń PostgreSQL, dlatego zrozumienie jej jest cenną wiedzą na poziomie seniora do architektury produkcyjnych baz danych.

Dwie kluczowe korzyści są krytyczne dla poważnych aplikacji: **wysoka dostępność** (jeśli główna baza danych się zawiedzie, replika może być promowana do przejęcia roli, minimalizując przestój — niezbędne dla systemów, które muszą być dostępne) i **skalowanie odczytów** (kierowanie zapytań tylko do odczytu do replik odciąża primary, pozwalając systemowi obsługiwać znacznie więcej ruchu odczytu — wartościowe dla obciążeń intensywnie korzystających z odczytów).

Zrozumienie **replikacji strumieniowej** (primary strumieniuje swój WAL do replik, które pozostają zsynchronizowane i mogą obsługiwać odczyty) jest fundamentem.

Znajomość kompromisu **synchroniczna vs asynchroniczna** jest ważna: asynchroniczna (domyślnie — szybsze zapisy, ale mały okres potencjalnej utraty danych przy failoverze) versus synchroniczna (brak utraty danych, ale wolniejsze zapisy) — decyzja trwałości kontra wydajność wpływająca na niezawodność.

Zrozumienie **logical replication** (replikowanie określonych tabel poprzez pub/sub, przydatne dla migracji, między wersjami i częściowej/selektywnej replikacji) poszerzają opcje.

Wiedza, że **narzędzia HA** (Patroni, repmgr, zarządzany cloud Postgres) automatyzują failover, i że routing odczytu/zapisu kieruje ruch odpowiednio, to praktyczna wiedza architektoniczna.

Ponieważ wysoka dostępność i skalowalność to niezbędne wymagania dla produkcyjnych systemów bazodanowych, a replikacja (z jej failoverem HA, skalowaniem odczytów, kompromisem trwałości sync/async i logical replication dla elastyczności) jest głównym mechanizmem, jaki PostgreSQL zapewnia, zrozumienie replikacji to ważna wiedza na poziomie seniora do architekturowania niezawodnych, skalowalnych wdrożeń Postgres — często istotny problem dla systemów produkcyjnych i temat demonstrujący zrozumienie dostępności bazy danych i skalowania, którym powinni się wykazać kandydaci do ról seniora na stanowiskach bazodanowych/backendowych.