Kuinka replikaatio toimii PostgreSQL:ssä?

Question

Accepted Answer

**Replikaatio** kopioi tietoja **pääpalvelimesta** yhdelle tai useammalle **replika** (standby) -palvelimelle — korkean saatavuuden (failover, jos pääpalvelin epäonnistuu) ja luku-skaalauksen (jaa lukukyselyt) vuoksi. PostgreSQL käyttää pääasiassa **streaming replication** -replikaatiota (fyysinen), joka perustuu write-ahead log -lokiin (WAL).

## Streaming (fyysinen) replikaatio

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

Pääpalvelin virtauttaa **WAL**-lokinsa (write-ahead log — tietue jokaisesta muutoksesta) repliikoihin, jotka soveltavat sitä pysyäkseen synkronoituina. Repliikat ovat vain luettavia kopioita, jotka voivat palvella lukukyselyitä.

## Edut: HA ja luku-skaalaus

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

## Synkroninen vs asynkroninen replikaatio

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

## Looginen replikaatio (eri malli)

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

## Korkea saatavuus käytännössä

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

## Miksi sillä on merkitystä

Replikaatio on tärkeä **erittäin saatavissa olevien ja skaalattavien** PostgreSQL-käyttöönotosten rakentamisessa, joten sen ymmärtäminen on arvokasta senior-tason tietoa tuotantotietokannan arkkitehtuurista.

Kaksi ydinettua ovat kriittisiä vakavissa sovelluksissa: **korkea saatavuus** (jos pääpalvelin epäonnistuu, replika voidaan ylennnystää ottamaan sen paikka, mikä minimoi seisokit — välttämätöntä järjestelmille, joiden on pysyttävä saatavilla) ja **luku-skaalaus** (vain lukua varten tarkoitettujen kyselyjen ohjaaminen replikoihin vähentää kuormaa pääpalvelimelta, jolloin järjestelmä voi käsitellä paljon enemmän lukuliikennettä — arvokasta lukuintensiivisille työkuormille).

**Streaming replication** -replikaation ymmärtäminen (pääpalvelin virtauttaa WAL:ansa replikoihin, jotka pysyvät synkronoituina ja voivat palvella lukukyselyitä) on perusta.

**Synkronisen vs asynkronisen** kompromissin tunteminen on tärkeää: asynkroninen (oletus — nopeammat kirjoitukset mutta pieni mahdollisen tietojen menetyksen ikkuna failoverin yhteydessä) versus synkroninen (ei tietojen menetystä mutta hitaammat kirjoitukset) — kestävyyden ja suorituskyvyn päätös, joka vaikuttaa luotettavuuteen.

**Loogisen replikaation** ymmärtäminen (spesifisten taulukoiden replikaatio pub/sub:in kautta, hyödyllinen migraatioissa, eri versioissa ja osittaisessa/valikoivassa replikaatiossa) laajentaa vaihtoehtoja.

Tiedon siitä, että **HA-työkalut** (Patroni, repmgr, hallinnoidut cloud Postgres) automatisoivat failoverin, ja että luku/kirjoitus-reititys ohjaa liikennettä asianmukaisesti, on käytännön arkkitehtuuritietoa.

Koska korkea saatavuus ja skaalattavuus ovat olennaisia vaatimuksia tuotantotietokannan järjestelmille, ja koska replikaatio (sen HA failover-kyvyllä, luku-skaalauksen kanssa, synkronisen/asynkronisen kestävyyden kompromissin kanssa, ja loogisella replikaatiolla joustavuutta varten) on ensisijainen mekanismi, jonka PostgreSQL tarjoaa niille, replikaation ymmärtäminen on tärkeää senior-tason tietoa luotettavien ja skaalattavien Postgres-käyttöönotosten arkkitehtuurisäätöistä — usein relevantti huolenaihe tuotantojärjestelmille ja aihe, joka osoittaa ymmärryksen tietokannan saatavuudesta ja skaalauksesta, jota odotetaan senior tietokanta-/backend-rooleissa.