Aktuální stav správy zálohování Open Source pro PostgreSQL

Existuje mnoho způsobů, jak řešit zálohování clusteru PostgreSQL. Existuje několik článků a blogů, které představují různé technologie, pomocí kterých můžeme uložit naše drahocenná data v PostgreSQL. Existují řešení logického zálohování, fyzické zálohování na úrovni OS, na úrovni souborového systému a tak dále. Zde v tomto blogu se nebudeme zabývat teoretickou částí, která je dostatečně pokryta různými blogy a články a také oficiální dokumentací.

Tento blog se zaměřuje na stav různých dostupných nástrojů a řešení a snaží se prezentovat důkladné srovnání založené na reálných zkušenostech. Tento článek se v žádném případě nesnaží propagovat nějaký konkrétní produkt, moc se mi líbí všechny nástroje, řešení a technologie popsané v tomto blogu. Cílem je zaznamenat jejich silné a slabé stránky a nasměrovat koncového uživatele k tomu, který nástroj by nejlépe vyhovoval jeho prostředí, infrastruktuře a specifickým požadavkům. Zde je pěkný článek popisující zálohovací nástroje pro PostgreSQL na různých úrovních.

Nebudu popisovat, jak používat různé nástroje v tomto blogu, protože tyto informace jsou zdokumentovány ve výše uvedeném blogu a také v oficiálních dokumentech a dalších zdrojích na internetu. Ale popíšu klady a zápory tak, jak jsem je zažil v praxi. V tomto blogu se zabýváme výhradně klasickými fyzickými zálohami PostgreSQL založenými na PITR závislých na:

• pg_basebackup nebo pg_start_backup()/pg_stop_backup
• fyzická kopie
• archivace WAL nebo streamování replikace

Existuje několik skvělých produktů a řešení, některé jsou open source a zdarma k použití, zatímco jiné jsou komerční. Podle mého nejlepšího vědomí to jsou:

• pgbarman by 2ndquadrant (zdarma)
• pgbackrest (zdarma)
• pg_probackup od Postgres Professional (zdarma)
• BART od EDB (komerční)

Neměl jsem možnost vyzkoušet BART, protože běží na variantách Linuxu, které nepoužívám. V tomto blogu zahrnu své vlastní myšlenky a dojmy při interakci s příslušnými autory/komunitou/správci každého řešení, protože jde o velmi důležitý aspekt, který se na začátku obvykle podceňuje. Trochu terminologie pro lepší pochopení různých termínů v každém z nástrojů:

pgbarman

Pgbarman nebo jen barman je nejstarší z těchto nástrojů. Nejnovější vydání je 2.6 (vydáno, když jsem měl tento blog v provozu! což je skvělá zpráva).

Pgbarman podporuje základní zálohu dvěma způsoby:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

a přenos WAL přes:

• Archivace WAL
  • přes rsync
  • přes barman-wal-archive / put-wal
• WAL prostřednictvím streamingové replikace s replikačním slotem
  • Asynchronní
  • Synchronní

To nám dává 8 out of the box kombinací, pomocí kterých můžeme použít barmana. Každý má své pro a proti.

Základní záloha přes pg_basebackup (backup_method =postgres)

Výhody:

• nejnovější/moderní způsob
• spoléhá na osvědčenou základní technologii PostgreSQL
• doporučeno oficiálními dokumenty

Nevýhody:

• žádné přírůstkové zálohování
• žádné paralelní zálohování
• žádná síťová komprese
• žádná deduplikace dat
• žádný limit šířky pásma sítě

Základní zálohování přes rsync (backup_method =rsync)

Výhody:

• staré a osvědčené
• Přírůstkové zálohování
• deduplikace dat
• komprese sítě
• paralelní zálohování
• limit šířky pásma sítě

Nevýhody:

• není doporučeným (autory) způsobem

Přenos WAL prostřednictvím archivace WAL (přes rsync)

Výhody:

• jednodušší nastavení

Nevýhody:

• Žádné RPO=0 (nulová ztráta dat)
• žádný způsob, jak se zotavit z dlouhých a přetrvávajících selhání sítě

Přenos WAL prostřednictvím archivace WAL (přes barman-wal-archive / put-wal)

Výhody:

• nejnovější a doporučený způsob (zavedený ve verzi 2.6)
• spolehlivější/bezpečnější než rsync

Nevýhody:

• Žádné RPO=0 (nulová ztráta dat)
• stále neexistuje způsob, jak se zotavit z dlouhých a přetrvávajících selhání sítě

Přenos WAL prostřednictvím streamování WAL s replikačním slotem (přes pg_receivewal)

Výhody:

• modernější (a doporučené)
• RPO=0 (nulová ztráta dat) v synchronním režimu

Nevýhody:

• vždy spojené s replikačním slotem. V případě výpadků sítě se může zvětšit

Takže zatímco pg_basebackup (metoda postgres) vypadá jako budoucnost pro pgbarman, ve skutečnosti všechny vychytané funkce přicházejí s metodou rsync. Pojďme si tedy vyjmenovat všechny funkce Barmana podrobněji:

• Vzdálený provoz (zálohování/obnovení)
• Přírůstkové zálohy. Jednou ze skvělých funkcí barmana jsou přírůstkové zálohy, které jsou založeny na porovnání úrovně souborů databázových souborů se soubory poslední zálohy v katalogu. V barmanovi termín „diferenciál“ odkazuje na jiný koncept:Rozdílová záloha je podle barmanské terminologie poslední záloha + jednotlivé změny od poslední zálohy. Dokumenty Barman říkají, že poskytují rozdílové zálohy prostřednictvím WAL. Inkrementální zálohy Barman fungují na úrovni souboru, což znamená, že pokud se soubor změní, přenese se celý soubor. Je to jako pgbackrest a na rozdíl od některých jiných nabídek, jako je pg_probackup nebo BART, které podporují rozdílové/přírůstkové zálohy na úrovni bloku. Přírůstkové zálohy Barman jsou specifikovány pomocí:reuse_backup =odkaz nebo kopie. Definováním „kopírování“ dosáhneme zkrácení doby zálohování, protože se přenesou a zálohují pouze změněné soubory, ale stále nedojde k omezení místa, protože nezměněné soubory jsou zkopírovány z předchozí zálohy. Definováním „link“ jsou nezměněné soubory pevně propojeny (ne zkopírovány) z poslední zálohy. Tímto způsobem dosáhneme jak redukce času, tak redukce prostoru. Nechci v tom žádným způsobem přinášet další zmatky, ale ve skutečnosti jsou přírůstkové zálohy barman přímo srovnatelné s přírůstkovými zálohami pgbackrest, protože barman zachází (přes odkaz nebo kopírování) s přírůstkovou zálohou efektivně jako s plnou zálohou. V obou systémech se tedy přírůstková záloha zabývá soubory, které byly změněny od poslední zálohy. Co se však týká rozdílových záloh, znamená to v každém z výše uvedených systémů něco jiného, ​​jak uvidíme níže.
• Zálohování z pohotovostního režimu. Barman dává možnost provádět většinu operací základní zálohy z pohotovostního režimu, čímž uvolňuje primární od přidané IO zátěže. Pamatujte však, že WAL musí stále pocházet z primárního. Nezáleží na tom, jestli používáte archive_command nebo WAL streaming přes replikační sloty, zatím nemůžete (v době psaní tohoto článku s barmanem ve verzi 2.6) přesunout tento úkol do pohotovostního režimu.
• paralelní úlohy pro zálohování a obnovu
• Rozsáhlá a komplexní sada nastavení uchovávání založená na:
  • Redundance (počet záloh, které je třeba zachovat)
  • Okno obnovy (jak do minulosti by měly být zálohy uchovávány)
  Podle mého názoru z uživatelského hlediska je výše uvedené skvělé. Uživatel může definovat reuse_backup =odkaz a okno obnovy a nechat barmana (jeho cron job), aby se postaral o zbytek. Žádné diff/incr/úplné zálohy atd., o které byste se museli starat, plánovat nebo spravovat. Systém (barman) prostě dělá správnou věc transparentně.
• Programování vlastních skriptů před/po události.
• Přemapování tabulkového prostoru

To jsou nejlepší přednosti barmana. A to je skutečně téměř více, než by průměrný DBA požadoval od nástroje pro zálohování a obnovu. Existuje však několik bodů, které by mohly být lepší:

• Konference není tak aktivní a správci jen zřídka píší nebo odpovídají na otázky
• Žádná funkce pro obnovení neúspěšného/přerušeného zálohování
• Replikační sloty nebo použití rsync/barman-wal-archive pro archivaci nejsou shovívavé v případě selhání sítě nebo jiných selhání zálohovacího místa. V obou případech, pokud je výpadek sítě dostatečně dlouhý a změny v DB stojí za mnoho souborů WAL, pak primární bude trpět tím, že na zařízení nezbývá místo a nakonec se zhroutí. (není dobrá věc). Slibné je, že barman nyní poskytuje alternativní (k rsync) způsob přenosu WAL tak, aby byla dodatečná ochrana např. V budoucnu by mohlo být implementováno vyčerpání prostoru pg_wal, což by spolu se záložním životopisem skutečně udělalo barmana dokonalého, alespoň pro mě.

pgbackrest

Pgbackrest je současným trendem mezi open source zálohovacími nástroji, a to především pro svou efektivitu vypořádat se s velmi velkými objemy dat a mimořádnou péči, kterou jeho tvůrci věnují validaci záloh pomocí kontrolních součtů. V době psaní tohoto článku je ve verzi v2.09 a dokumenty naleznete zde. Uživatelská příručka může být mírně zastaralá, ale ostatní dokumenty jsou velmi aktuální a přesné. Pgbackrest spoléhá na archivaci WAL pomocí vlastního archive_command a vlastního mechanismu přenosu souborů, který je lepší a bezpečnější než rsync. Takže pgbackrest je docela vpřed, protože nedává větší sadu možností, které barman poskytuje. Protože se nejedná o žádný synchronní režim, pgbackrest přirozeně nezaručuje RPO=0 (nulová ztráta dat). Pojďme si popsat koncepty pgbackrest:

• Záloha může být:
  • Plná. Úplná záloha zkopíruje celý klastr databáze.
  • Diferenciální (rozdíl). Rozdílová záloha zkopíruje pouze soubory, které byly změněny od poslední plné zálohy. Pro úspěšné obnovení musí být platná rozdílová záloha i předchozí plná záloha.
  • Přírůstkové (přírůstkové). Přírůstková záloha zkopíruje pouze soubory, které byly změněny od poslední zálohy (což může být plná záloha, rozdílová nebo dokonce přírůstková záloha). Podobně jako u rozdílové zálohy musí být pro úspěšné obnovení všechny předchozí požadované zálohy (včetně této zálohy, nejnovějšího rozdílu a předchozí plné) platné.
• Stanza je definice všech požadovaných parametrů klastru PostgreSQL. Normální PostgreSQL server má svou vlastní stanzu, zatímco záložní servery budou mít jednu stanzu pro každý cluster PostgreSQL, který zálohují.
• Konfigurace je místo, kde jsou uchovávány informace o stanzích (obvykle /etc/pgbackrest.conf)
• Úložiště je místo, kde pgbackrest uchovává WAL a zálohy

Uživateli se doporučuje, aby postupoval podle dokumentace, jak sama dokumentace navrhuje, odshora dolů. Nejdůležitější vlastnosti pgbackrest jsou:

• Paralelní zálohování a obnova
• Není nutný přímý přístup SQL k serveru PostgreSQL
• Místní/vzdálené ovládání
• Uchování na základě:
  • uchování úplné zálohy (počet úplných záloh, které se mají ponechat)
  • uchování rozdílových záloh (počet záloh rozdílů, které se mají zachovat)
  Přírůstkové zálohy nemají vlastní uchovávání a jejich platnost vyprší, jakmile vyprší platnost předchozí zálohy. Uživatel tak může definovat plán pořizování úplných záloh a postupnou sadu rozdílových záloh mezi nimi.
• Zálohování z pohotovostního režimu. Některé soubory stále musí pocházet z primárního zdroje, ale hromadné kopírování probíhá v pohotovostním režimu. Přesto musí WAL pocházet z primárního.
• Integrita zálohy. Lidé za pgbackrest jsou extrémně opatrní, pokud jde o integritu záloh. Každý soubor je při zálohování kontrolován a také je zkontrolován po obnovení, aby se zajistilo, že žádná problémová hardwarová nebo softwarová chyba nemůže způsobit chybnou obnovu. Pokud jsou v clusteru PostgreSQL povoleny kontrolní součty na úrovni stránky, pak se také počítají pro každý soubor. Kromě toho se pro každý soubor WAL počítají kontrolní součty.
• Pokud je komprese zakázána a jsou povoleny pevné odkazy, je možné vyvolat cluster přímo z katalogu. To je extrémně důležité pro velké databáze s více TB.
• Obnovení neúspěšného/přerušeného zpětného chodu. Velmi užitečné v případě nespolehlivých sítí.
• Delta restore:Ultra rychlé obnovení pro velké databáze bez čištění celého clusteru.
• Asynchronní a paralelní odesílání WAL na záložní server. To je jedna z nejsilnějších stránek pgbackrest. Archivátor PostgreSQL pouze kopíruje do spoolu pomocí archivace-push a náročná úloha přenosu a zpracování probíhá v samostatném procesu pgbackrest. To umožňuje masivní přenosy WAL a zároveň zajišťuje nízkou dobu odezvy PostgreSQL.
• Přemapování tabulkového prostoru
• Podpora Amazon S3
• Podpora pro maximální velikost WAL ve frontě. Když zálohovací stránka nefunguje nebo selže síť, použití této možnosti se bude vysmívat, jako by byla archivace úspěšná, což PostgreSQL umožní odstranit WAL bránící zaplnění pg_wal, a tak zachránit server pgsql před potenciální PANIKOU.

Funkce pgbackrest tedy klade velký důraz, pokud jde o ověřování dat a výkon, není překvapením, že jej používají největší a nejrušnější instalace PostgreSQL. Je tu však jedna věc, kterou lze zlepšit:

• Bylo by opravdu užitečné mít „liberálnější“ možnost, pokud jde o uchovávání, tj. poskytnout způsob, jak deklarativně specifikovat určitou dobu uchování, a poté nechat pgbackrest, aby se podle potřeby vypořádal s plnými/rozdílnými/incr zálohami.

pg_probackup

Pg_proback je další slibný nástroj pro zálohování. Původně je založen na pg_arman. Klade důraz na výkon zálohy. Je založen na katalozích a instancích, které jsou velmi podobné ostatním nástrojům, takže máme. Mezi jeho hlavní vlastnosti patří:

• Rozsáhlá podpora na úrovni zálohování od:
  • Úplné zálohy
  • Přírůstek tří typů:
    • Záloha PAGE. Změny úrovně zjištěné skenováním WAL. Vyžaduje plný přístup k nepřerušované sekvenci WAL od předchozí zálohy.
    • DELTA záloha. Do zálohy se zkopírují pouze změněné stránky. Nezávisle na archivaci WAL klade určitou zátěž na server.
    • Záloha PTRACK. Vyžaduje speciální záplatování jádra pgsql. Funguje tak, že udržuje bitmapu za chodu, jakmile jsou stránky upraveny. Opravdu rychlé zálohování s minimální zátěží serveru.
• Zálohy lze také rozdělit na:
  • Autonomní zálohování. Tito nemají žádné požadavky na WAL mimo zálohu. Žádný PITR.
  • Archivujte zálohy. Ty se spoléhají na nepřetržitou archivaci a podporují PITR.
• vícevláknový model (na rozdíl od barmana, pgbackrest a samozřejmě samotného PostgreSQL, které se řídí víceprocesovým modelem)
• Konzistence dat a ověřování na vyžádání bez obnovení
• Zálohování z pohotovostního režimu bez přístupu k primárnímu.
• Výrazná specifikace zásad uchovávání, kde lze redundanci použít způsobem AND spolu s oknem. Slučování záloh (prostřednictvím sloučení) je podporováno převodem předchozích přírůstkových záloh na plné, což je způsob, jak uvolnit místo a poskytnout metodu pro plynulé střídání záloh.

Takže pg_probackup poskytuje sadu skvělých funkcí s důrazem na výkon, což by bylo přínosem pro velké instalace. Stále však některé věci chybí, konkrétně:

• Žádná oficiální verze nepodporuje vzdálené zálohování. To znamená, že pg_probackup musí běžet na stejném hostiteli jako cluster pgsql. (Existuje vývojová větev, která se zabývá zálohováním ze vzdáleného místa a také archivací na vzdálený záložní server)
• Žádná podpora pro neúspěšné obnovení zálohy.

Výše uvedené odstavce můžeme shrnout pomocí matice funkcí, jako je ta níže.

ClusterControl

ClusterControl poskytuje funkcionalitu buď pro generování okamžité zálohy, nebo pro její naplánování a automatizaci úlohy jednoduchým a rychlým způsobem.

Můžeme si vybrat mezi dvěma způsoby zálohování, pgdump (logický) a pg_basebackup (binární). Můžeme také určit, kam se mají zálohy ukládat (na databázovém serveru, na serveru ClusterControl nebo v cloudu), úroveň komprese a šifrování.

S ClusterControl můžeme také použít funkci Point-in-Time Recovery a ověření zálohy k ověření vygenerované zálohy.