Fyzické replikační mechanismy v PostgreSQL

Postgres přichází s funkcemi fyzické a logické replikace. Čtěte dále a dozvíte se více o různých aspektech fyzické replikace.

Fyzická replikace

Metody fyzické replikace se používají k udržování úplné kopie celých dat jednoho klastru (v Postgresu klastru je sada databází spravovaných jedním hlavním procesem serveru Postgres zvaným postmaster ), obvykle na jiném stroji. Zdrojový stroj se nazývá primární v žargonu Postgres a cíl se nazývá pohotovostní režim .

Horké, teplé a „studené“ pohotovostní režimy

Pohotovostní server, který je udržován co nejaktuálnější s primárním v reálném čase a umožňuje klientům provádět transakce pouze pro čtení, se nazýváhorký pohotovostní režim, nebo lidověji replika pro čtení . Horké pohotovostní režimy byly přidány do Postgresu ve verzi 9, předtím byly pouze teplé pohotovostní režimy. Teplý pohotovostní režim je podobný horkému pohotovostnímu režimu, kromě toho, že neumožňuje klientům se k němu připojit.

(Ostatně:Hot standby nemohou provádět dotazy, které vytvářejí dočasné tabulky. Toto je omezení Postgresu.)

„Studený“ pohotovostní režim (není oficiální termín) je obvykle záložní server, který se nespustí až do převzetí služeb při selhání. Vzhledem k tomu, že studený pohotovostní režim není spuštěn a neběží, je možné, že při spuštění bude muset nejprve provést nevyřízené změny, než bude moci začít přijímat klientská připojení.

Soubory WAL

V normálním průběhu operací generuje PostgreSQL server uspořádanou sérii záznamů WAL (zápis dopředu). Jedná se v podstatě o protokol změn, podobně jako Redis' AOF nebo binlog MySQL. Fyzická replikace je ve svém jádru přenos těchto záznamů na jiný počítač a přimět druhého poštmistra, který tam běží, aby tyto záznamy přijal a aplikoval do své místní databáze.

Záznamy WAL jsou rozděleny do stejně velkých (obvykle 16 MB) souborů nazývanýchsegmenty WAL nebo jen soubory WAL . Tyto soubory jsou vytvořeny v adresáři s názvem pg_wal v datovém adresáři clusteru (pg_wal se jmenoval pg_xlog ve verzích Postgres starších než 10). Staré soubory WAL jsou zahozeny, když již nejsou potřeba (a také na základě několika konfiguračních parametrů).

Režim obnovení

Postmaster lze spustit v režimu zvaném recovery mode , umístěním platného konfiguračního souboru s názvem recovery.conf v adresáři dat clusteru. V režimu obnovy bude Postgres importovat a aplikovat pouze soubory WAL generované primárním serverem a sám o sobě nevygeneruje žádné soubory WAL. Teplé servery a servery v pohotovostním režimu běží v režimu obnovy.

Po spuštění v režimu obnovy se Postgres nejprve pokusí importovat všechny soubory WAL dostupné v archivu (více o tom níže). Když archiv nemá žádné další soubory WAL, které by mohl nabídnout, pokusí se importovat všechny soubory ležící kolem init pg_wal adresář. Až budou hotové, pokud je primární připojení nakonfigurováno a standby_modeset na on v recovery.conf se Postgres připojí k primární a vytáhne a použije nové záznamy WAL, jakmile budou vytvořeny na primární.

Zapsat zásilku

Představte si, že máte spouštěč, který bude vyvolán na primárním serveru při každém vytvoření nového souboru WAL. Tento spouštěč pak může zkopírovat nový soubor WAL do jiného počítače pomocí řekněme rsync a umístěte jej do pg_wal adresář postmaster běžícího v režimu obnovy. Můžete udělat pohotovostní režim takto?

Odpověď je ano a skutečně to byl standardní postup před přidáním streamingreplication do Postgres v9. Tento postup se nazývá zásilka protokolu .

Spouštěč je skript shellu, který lze nakonfigurovat pomocí příkazu archive_command. Název a cestu k souboru WAL lze předat skriptu.

Archivace WAL

Namísto synchronizace přes soubor WAL, řekněme, že jej zkopírujeme do S3 bucketoru adresáře připojeného k NFS, který je přístupný také z pohotovostního počítače. Toto sdílené umístění bude nyní obsahovat všechny soubory WAL generované primárním serverem. se stane archivem a proces ukládání souborů WAL do archivu se nazývá nepřetržitá archivace nebo jednoduše archivace WAL .

Inverzní k této operaci – načítání souborů WAL z archivu do režimu arecovery Postgres – lze nakonfigurovat pomocí příkazu restore_command.Podobně jako archive_command , toto je také cesta ke skriptu shellu. Správce pošty běžící v režimu obnovy ví, který soubor WAL chce. Název souboru lze předat skriptu.

Jako příklad uvádíme příkazy pro archivaci a obnovu pro ukládání a načítání souborů WAL do az bucketu S3:

archive_command = 's3cmd put %p s3://BUCKET/path/%f' # in postgresql.conf
restore_command = 's3cmd get s3://BUCKET/path/%f %p' # in recovery.conf

Při spouštění v režimu obnovy, pokud restore_command je nakonfigurován, Postgres se nejprve pokusí načíst soubory WAL z archivu.

pg_standby

V režimu obnovy Postgres neví a nemůže předem vědět, kolik souborů WAL bylo dosud vygenerováno. Pokud je příkaz restore_command nakonfigurován, bude jej Postgres opakovaně vyvolávat s progresivními názvy souborů WAL (jména jsou v předvídatelném pořadí), dokud příkaz nevrátí chybu.

Například příkaz obnovení dokázal uspokojit požadavky na soubory WAL000000010000000000000001 přes 00000001000000000000001A ale selže pro00000001000000000000001B protože nebyl nalezen v umístění archivu. Při absenci souborů WAL z jiných zdrojů bude Postgres předpokládat, že soubor WAL 00000001000000000000001B ještě musí být vygenerován primární a dokončí obnovu po použití 00000001000000000000001A .

Zvažte, co by se stalo, kdyby příkaz obnovení čekal na soubor00000001000000000000001B být k dispozici, spíše než odejít s chybou, protože nebyl nalezen. Postgres bude i nadále čekat na příkaz obnovení, a proto bude nadále v režimu obnovy.

Toto je platná konfigurace a platný způsob nastavení teplého pohotovostního režimu.

Postgres se dodává s příkazem pg_standby, který lze použít k nastavení teplého pohotovostního režimu tímto způsobem, pokud je archiv adresář.pg_standby bude čekat, až bude soubor dostupný, pokud jej nelze najít.

Příkazy pro archivaci a obnovu pomocí pg_standby budou vypadat takto:

archive_command = 'cp %p /some/path/%f'         # in postgresql.conf
restore_command = 'pg_standby /some/path %f %p' # in recovery.conf

Streamování replikace

Po zpracování archivovaných souborů WAL i souborů v pg_wal adresář, Postgres se může připojit k primárnímu serveru přes síť a opakovaně načítat a aplikovat nové soubory WAL, jakmile jsou vytvořeny. Tato funkce, přidaná v Postgres 9, se nazývá replikace streamování .

Primární server, ke kterému se chcete připojit, lze zadat v souboru recovery.conf:

# recovery.conf
standby_mode = on
primary_conninfo = 'host=10.0.1.10 user=repl password=p@ssw0rd'

Horký pohotovostní režim

Ve výchozím nastavení, v režimu obnovy, Postgres nebude přijímat klientská připojení a odmítne je s chybovými zprávami „databázový systém je v režimu obnovy“. Přidáním řádku hot_standby = on v recovery.conf můžete vytvořit připojení klientů Postgresaccept a umožnit jim provádět transakce pouze pro čtení:

# recovery.conf
hot_standby = on

Obvykle není důvod vypínat hot_standby.

Dokument PostgreSQL obsahuje další informace o nastavení a spuštění pohotovostního režimu v režimu „horkého pohotovostního režimu“.

Replikační sloty

Replikační sloty byly představeny v Postgres 9.4. Jsou mechanismem pro přesné a trvalé sledování toho, jak daleko pohotovostní režim zaostává za primárním. To umožňuje primárnímu zajistit, že soubory WAL, které jsou stále potřebné pro pohotovostní režim, nebudou smazány.

Před replikačními sloty to primární nemohl určit a vy byste se dostali do situací, kdy pohotovostní režim zůstal uvízlý, protože soubor WAL, který potřeboval, byl odstraněn primárním. Tento problém samozřejmě mohou vyřešit archivy WAL. Bez archivu WAL však jedinou možností bylo znovu sestavit pohotovostní režim z nové zálohy.

Více o replikačním slotu si můžete přečíst zde.

Kroky k nastavení horkého pohotovostního režimu

Pojďme se podívat na kroky potřebné k nastavení horkého pohotovostního režimu pro stávající primární.

1. Vytvořit uživatele replikace

Nejprve potřebujeme, aby se uživatel pro pohotovostní režim připojil jako:

$ psql -p 6000
psql (11.2 (Debian 11.2-1.pgdg90+1))
Type "help" for help.

postgres=# CREATE USER repluser REPLICATION PASSWORD 'p@ssw0rd';
CREATE USER

A odpovídající změny v pg_hba.conf :

# TYPE  DATABASE        USER          ADDRESS        METHOD
host    replication     repluser      standby-ip/32  md5
# (replace standby-ip)

Samozřejmě můžete použít jakýkoli standardní autentizační mechanismus PostgreSQL. Uživatel musí mít oprávnění k replikaci a přihlášení a nevyžaduje přístup k žádné konkrétní databázi.

Nezapomeňte znovu načíst primární server, aby se změny v pg_hba.conf projevily.

2. Udělejte zálohu

Pohotovostní režim musí začít ze zálohy primárního. Můžete a měli byste to udělat pomocí pg_basebackup s novým replikačním slotem:

pg_basebackup -h primary-ip -p 6000 -U repluser -C -S slot_standby1 -R -D standby

Toto se připojí k primární na primary-ip:6000 s uživatelem, kterého jsme právě vytvořili, a vezme si jeho zálohu do adresáře standby . Nový replikační slotslot_standby1 je vytvořen.

3. Přidejte recovery.conf v pohotovostním režimu

Tento slot použijeme jako náš záložní replikační slot, aby byla zajištěna kontinuita ze zálohy.

Zeptali jsme se pg_basebackup vytvořit recovery.conf pro nás výše (volba „-R“). Pojďme se na to podívat:

$ cat standby/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=repluser password=''p@ssw0rd'' host=primary-ip port=6000 sslmode=prefer sslcompression=0 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'slot_standby1'

To je vlastně docela dobré a nemusíme to dále upravovat. Nyní jednoduše aktivujte pohotovostní režim:

o$ pg_ctl -D standby -l log_standby -o --port=6001 start
waiting for server to start.... done
server started
postgres@stg1:/tmp/demo$ cat log_standby
2019-06-19 09:17:50.032 UTC [21733] LOG:  listening on IPv4 address "127.0.0.1", port 6001
2019-06-19 09:17:50.034 UTC [21733] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.6001"
2019-06-19 09:17:50.067 UTC [21734] LOG:  database system was interrupted; last known up at 2019-06-19 09:12:05 UTC
2019-06-19 09:17:50.111 UTC [21734] LOG:  entering standby mode
2019-06-19 09:17:50.119 UTC [21734] LOG:  redo starts at 0/2000028
2019-06-19 09:17:50.120 UTC [21734] LOG:  consistent recovery state reached at 0/20000F8
2019-06-19 09:17:50.120 UTC [21733] LOG:  database system is ready to accept read only connections
2019-06-19 09:17:50.138 UTC [21739] LOG:  started streaming WAL from primary at 0/3000000 on timeline 1

A to je vše! Soubor protokolu označuje, že je spuštěna a spuštěna streamovaná replikace. Nyní byste měli být schopni se připojit k pohotovostnímu režimu na portu 6001, spouštět dotazy pouze pro čtení a sledovat, jak se změny replikují z primárního víceméně v reálném čase.

Další kroky

Dokumenty PostgreSQLdocs jsou skvělým místem, kde můžete začít hlouběji zkoumat všechny funkce Postgres související s replikací. Budete se chtít podívat na témata, jako je zpožděná replikace, kaskádová replikace, synchronní pohotovostní režimy a další.

Přestože Postgres přichází s působivou sadou funkcí, stále existují případy použití, které nejsou podporovány. Tato wikistránka Postgres obsahuje seznam nástrojů třetích stran, které poskytují další funkce související s replikací.