27. Replikace a vysoká dostupnost databází (úvod)

Úvod a kontext

Záloha z minulé lekce chrání data před ztrátou, ale obnova z ní trvá
minuty až hodiny — po tu dobu je aplikace nedostupná. Pro služby, kde
výpadek databáze znamená přímou ztrátu peněz nebo důvěry uživatelů
(e-shop, bankovní aplikace), to nestačí. Řešením je replikace —
udržování živé kopie dat na dalším serveru, která může okamžitě převzít
provoz, pokud hlavní server selže. Tato lekce vysvětluje základní princip
replikace a vysoké dostupnosti databází, jako úvod do tématu, které se v
praxi dál prohlubuje podle konkrétní databáze a cloudové platformy.

Teorie

Primary-replica replikace

Nejběžnější model replikace relačních databází je primary-replica
(dříve se používalo označení master-slave): jeden server, primary,
přijímá všechny zápisy (INSERT/UPDATE/DELETE). Změny se z primary
serveru průběžně přenášejí na jeden nebo víc replik (replica),
které si udržují (téměř) identickou kopii dat.

Mechanismus přenosu u PostgreSQL i MySQL je založený na
transakčním logu — sekvenčním záznamu všech změn, které databáze
provedla (PostgreSQL tomu říká WAL, Write-Ahead Log; MySQL binlog).
Replika si tento log stahuje a přehrává u sebe, čímž reprodukuje stejné
změny se zpožděním v řádu milisekund až sekund.

Repliky se typicky používají dvěma způsoby:
- Vysoká dostupnost — pokud primary selže, jedna z replik se
povýší (promote) na nový primary a provoz pokračuje.
- Rozložení čtecí zátěže — aplikace posílá zápisy na primary, ale
čtecí dotazy (reporty, vyhledávání) rozděluje mezi repliky, čímž
primary odlehčí.

Synchronní vs. asynchronní replikace

• Asynchronní replikace — primary potvrdí zápis klientovi ihned, bez
  čekání na to, že ho replika přijala. Rychlejší (nižší latence zápisu),
  ale při pádu primary těsně po zápisu může být poslední transakce na
  replice ještě chybějící — hrozí ztráta několika posledních transakcí.
• Synchronní replikace — primary počká na potvrzení od (alespoň
  jedné) repliky, než sám potvrdí zápis klientovi. Garantuje nulovou
  ztrátu dat při failoveru, ale zvyšuje latenci každého zápisu a zápis
  selže, pokud je replika nedostupná.

Volba je kompromis mezi výkonem a bezpečností dat — kritické finanční
transakce často vyžadují synchronní replikaci alespoň k jedné replice,
zatímco běžné aplikace si vystačí s asynchronní kvůli lepšímu výkonu.

Failover — automatický i manuální

Failover je proces přepnutí provozu z havarovaného primary serveru na
repliku. Rozlišujeme:

• Manuální failover — administrátor ručně rozhodne a povýší repliku
  na primary. Bezpečnější (žádné automatické rozhodnutí za nejasných
  okolností), ale pomalejší (závisí na tom, kdy si problému někdo
  všimne a zasáhne).
• Automatický failover — specializovaný nástroj (např. Patroni pro
  PostgreSQL, nebo řízené služby jako AWS RDS Multi-AZ) průběžně
  kontroluje zdraví primary a při selhání sám povýší repliku bez
  lidského zásahu. Rychlejší reakce, ale riziko tzv. split-brain —
  situace, kdy si dva servery současně myslí, že jsou primary (např.
  kvůli výpadku sítě, ne skutečnému pádu databáze), a obě strany
  přijímají zápisy, které se rozejdou. Řešení split-brain problému
  (kvórum, fencing mechanismy) je jeden z nejsložitějších aspektů
  automatického failoveru.

Vysoká dostupnost v cloudu

Spravované databázové služby (AWS RDS Multi-AZ, Google Cloud SQL
s vysokou dostupností, Azure Database) tuto komplexitu z velké části
skrývají — poskytovatel automaticky udržuje synchronní repliku ve druhé
dostupnostní zóně a při selhání primary provede failover sám, obvykle do
minuty, bez potřeby vlastního nástroje jako Patroni. To je jeden z
hlavních důvodů, proč mnoho firem pro produkční databáze volí spravované
cloudové služby místo vlastní správy replikace.

Praktický příklad

Zjednodušené nastavení streamovací replikace v PostgreSQL — na primary
serveru v postgresql.conf:

wal_level = replica
max_wal_senders = 5

V pg_hba.conf povolení replikačního připojení z IP adresy repliky:

host    replication   replikator   10.0.0.20/32   scram-sha-256

Vytvoření uživatele s replikačním oprávněním na primary:

CREATE ROLE replikator WITH REPLICATION LOGIN PASSWORD 'silne-heslo';

Na serveru repliky vytvoření základní kopie dat z primary a spuštění v
režimu repliky (zjednodušený postup, verze se liší dle PostgreSQL):

pg_basebackup -h 10.0.0.10 -U replikator -D /var/lib/postgresql/16/main -P -R
sudo systemctl start postgresql

Přepínač -R automaticky vytvoří konfiguraci, díky které replika ví, ze
kterého primary serveru má proud změn stahovat.

Ověření, že replikace funguje, na primary serveru:

SELECT client_addr, state, sync_state
FROM pg_stat_replication;

Sloupec state = streaming znamená, že replika aktivně přijímá proud
změn; sync_state ukáže, zda jde o synchronní, nebo asynchronní repliku.

Shrnutí

Replikace primary-replica udržuje na dalším serveru živou kopii dat
přehráváním transakčního logu, přičemž volba mezi synchronní (bezpečnější,
pomalejší) a asynchronní (rychlejší, riziko ztráty posledních transakcí)
replikací je kompromisem mezi výkonem a bezpečností dat. Failover — ruční
nebo automatický — přepíná provoz na repliku při selhání primary, ale
automatický failover přináší riziko split-brain, které řeší specializované
nástroje nebo spravované cloudové databázové služby. Repliky se navíc
běžně používají i k rozložení čtecí zátěže, ne jen pro vysokou dostupnost.

Kontrolní otázky

1. Jaký je rozdíl mezi synchronní a asynchronní replikací a jaké jsou
   výhody/nevýhody obou?
2. Co je split-brain a proč je riziko vyšší u automatického failoveru než
   u manuálního?
3. K čemu se replika využívá kromě zajištění vysoké dostupnosti?
4. Proč mnoho firem pro produkční databáze volí spravované cloudové
   služby (např. AWS RDS Multi-AZ) místo vlastní správy replikace?