TL;DR :Logická replikace posílá změny řádek po řádku, fyzická replikace posílá změny bloků disku. Pro některé úkoly je lepší logická replikace, pro jiné fyzická.
Všimněte si, že v PostgreSQL 12 (aktuálním v době aktualizace) je logická replikace stabilní a spolehlivá, ale dosti omezená. Pokud se ptáte na tuto otázku, použijte fyzickou replikaci.
Replikace streamování může být logická replikace. Je to všechno trochu komplikované.
Doprava WAL vs streamování
Existují dva hlavní způsoby, jak odeslat data z hlavního serveru do repliky v PostgreSQL:
-
Doprava WAL nebo nepřetržitá archivace , kde jsou jednotlivé soubory s protokoly pro zápis napřed zkopírovány z
pg_xlogpříkazemarchive_commandběží na masteru na nějaké jiné místo.restore_commandnakonfigurovaný vrecovery.confrepliky běží na replice, aby načetl archivy, aby mohla replika přehrát WAL.To je to, co se používá pro replikaci v určitém okamžiku (PITR), který se používá jako metoda průběžného zálohování.
Není vyžadováno žádné přímé síťové připojení k hlavnímu serveru. Replikace může mít dlouhé zpoždění, zvláště bez
archive_timeoutsoubor. Přepravu WAL nelze použít pro synchronní replikaci. -
replikace streamování , kde je každá změna odeslána na jeden nebo více replikačních serverů přímo přes připojení TCP/IP, jakmile k tomu dojde. Repliky musí mít přímé síťové připojení, které hlavní server nakonfiguroval v souboru
recovery.confprimary_conninfomožnost.Streamová replikace má malé nebo žádné zpoždění, pokud je replika dostatečně rychlá, aby udržela krok. Lze jej použít pro synchronní replikaci . Pro PITR nelze použít streamingovou replikaci, takže pro průběžné zálohování není příliš užitečné. Pokud upustíte stůl na předlohu, jejda, spadne také na repliky.
Tyto dvě metody tedy mají různé účely.
Asynchronní versus synchronní streamování
Navíc je tu synchronní a asynchronní streamování replikace:
-
V asynchronní streamovací replikaci repliky mohou zaostávat za předlohou v době, kdy je předloha rychlejší/vytíženější. Pokud se hlavní server zhroutí, můžete ztratit data, která ještě nebyla replikována.
Pokud asynchronní replika příliš zaostává za masterem, může master zahodit informace, které replika potřebuje, pokud
max_wal_size(dříve se nazývalwal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master'spg_wal(waspg_xlog) se může zaplnit a zastavit hlavní server v práci, dokud se neuvolní místo na disku, pokudmax_wal_sizeje příliš vysoká nebo je použit slot. -
V synchronní replikaci master nedokončí potvrzení, dokud replika nepotvrdí, že transakci přijala. Nikdy neztratíte data, pokud se hlavní server zhroutí a vy musíte přepnout na repliku. Master nikdy nevyhodí data, která replika potřebuje, ani nezaplní svůj xlog a nedojde mu místo na disku kvůli zpoždění repliky. Na oplátku to může způsobit, že hlavní server zpomalí nebo dokonce přestane pracovat, pokud mají repliky problémy, a vždy to má určitý dopad na výkon hlavního serveru kvůli latenci sítě.
Pokud existuje více replik, pouze jedna je současně synchronní. Viz
synchronous_standby_names.
Nemůžete mít synchronní odesílání protokolu.
Ve skutečnosti můžete kombinovat odesílání protokolu a asynchronní replikaci, abyste se ochránili před nutností znovu vytvořit repliku, pokud příliš zaostává, aniž byste riskovali ovlivnění hlavního serveru. Toto je ideální konfigurace pro mnoho nasazení v kombinaci se sledováním toho, jak daleko je replika za hlavním serverem, aby bylo zajištěno, že je v přijatelných limitech obnovy po havárii.
Logické versus fyzické
Navíc to máme logické vs fyzické streaming replikace, jak je uvedeno v PostgreSQL 9.4:
-
Ve replikaci fyzického streamování změny se odesílají téměř na úrovni bloku disku, jako "na offsetu 14 stránky disku 18 vztahu 12311, zapsaná n-tice s hexadecimální hodnotou 0x2342beef1222...."
Fyzická replikace odešle vše :obsah každé databáze v instalaci PostgreSQL, všechny tabulky v každé databázi. Když
VACUUM FULLodešle položky indexu, odešle data celé nové tabulky , odesílá data o transakcích, které se vrátily zpět atd. Takže generuje spoustu "šumu" a posílá spoustu nadbytečných dat. Vyžaduje také, aby byla replika zcela identická, takže nemůžete dělat nic, co by vyžadovalo transakci, jako je vytváření dočasných nebo nepřihlášených tabulek. Dotazování na repliku zpožďuje replikaci, takže dlouhé dotazy na repliku je třeba zrušit.
Výměnou za to je jednoduché a efektivní aplikovat změny na replice a replika je spolehlivě přesně stejná jako předloha. DDL se replikuje transparentně, stejně jako všechno ostatní, takže nevyžaduje žádné zvláštní zacházení. Může také streamovat velké transakce, když k nim dojde, takže mezi potvrzením na hlavním serveru a potvrzením na replice je malá prodleva i v případě velkých změn.
Fyzická replikace je vyzrálá, dobře otestovaná a široce přijatá.
- replikace logického streamování , novinka ve verzi 9.4, odesílá změny na vyšší úrovni a mnohem selektivněji.
Replikuje vždy pouze jednu databázi. Odesílá pouze změny řádků a pouze pro potvrzené transakce a nemusí odesílat vakuová data, změny indexů atd. Může selektivně odesílat data pouze pro některé tabulky v databázi. Díky tomu je logická replikace velmi účinnější na šířku pásma.
Provoz na vyšší úrovni také znamená, že můžete provádět transakce na replikovaných databázích. Můžete vytvářet dočasné a nepřihlášené tabulky. Dokonce i normální tabulky, chcete-li. Můžete používat cizí obaly dat, pohledy, vytvářet funkce, cokoli chcete. Není třeba rušit dotazy, pokud běží příliš dlouho.
Logickou replikaci lze také použít k vytvoření replikace s více hlavními servery v PostgreSQL, což není možné pomocí fyzické replikace.
Výměnou za to však nemůže (aktuálně) streamovat velké transakce tak, jak k nim dochází. Musí počkat, až se zavážou. Mezi potvrzením velké transakce na hlavním serveru a aplikací na repliku tedy může být dlouhá prodleva.
Přehrává transakce striktně v pořadí potvrzení, takže malé rychlé transakce mohou uvíznout za velkou transakcí a být poměrně dlouho zpožděny.
DDL se nezpracovává automaticky. Musíte udržovat definice tabulek v synchronizaci mezi hlavní a replikou sami, nebo aplikace používající logickou replikaci musí mít k tomu vlastní prostředky. To může být komplikované.
Samotný proces aplikace je složitější než „zapsat nějaké bajty tam, kde mi to bylo řečeno“. Replika také vyžaduje více prostředků než fyzická replikace.
Současné implementace logické replikace nejsou vyspělé ani široce adoptované, ani nejsou obzvláště snadno použitelné.
Příliš mnoho možností, řekněte mi, co mám dělat
Fuj. Složité, co? A to jsem se ještě nedostal do podrobností o zpožděné replikaci, slotech, max_wal_size , časové osy, jak funguje propagace, Postgres-XL, BDR a multimaster atd.
Co byste tedy měli dělat ?
Neexistuje jediná správná odpověď. Jinak by PostgreSQL podporoval pouze tento jeden způsob. Existuje však několik běžných případů použití:
Pro zálohování a obnovu po havárii použijte pgbarman pro vytváření základních záloh a zachování WAL pro vás, což poskytuje snadnou správu nepřetržitého zálohování. Stále byste měli pravidelně používat pg_dump zálohy jako extra pojištění.
Pro vysokou dostupnost s nulovým rizikem ztráty dat použijte streaming synchronní replikaci.
Pro vysokou dostupnost s nízkým rizikem ztráty dat a lepším výkonem měli byste použít asynchronní datovou replikaci. Buď povolte archivaci WAL pro nouzový provoz, nebo použijte replikační slot. Pomocí externích nástrojů, jako je Icinga, můžete sledovat, jak daleko je replika za předlohou.
Odkazy
- průběžná archivace a PITR
- vysoká dostupnost, vyrovnávání zátěže a replikace
- nastavení replikace
- recovery.conf
- pgbarman
- repmgr
- wiki:replikace, shlukování a sdružování připojení