Je čas.
Zhruba před rokem jsme vydali PostgreSQL 10 s podporou nativní logické replikace. Jedním z použití logické replikace je umožnit upgrade mezi hlavními verzemi PostgreSQL s nízkými nebo žádnými prostoji. Doposud byla PostgreSQL 10 jedinou verzí PostgreSQL s nativní logickou replikací, takže nebylo mnoho příležitostí k upgradu tímto způsobem. (Logickou replikaci lze také použít pro přesun dat mezi instancemi na různých operačních systémech nebo architekturách CPU nebo s různými nízkoúrovňovými konfiguračními nastaveními, jako je velikost bloku nebo národní prostředí – chcete-li, sidegrading.) Nyní, když je PostgreSQL 11 blízko, bude více důvodů, proč tuto funkci využívat.
Nejprve porovnejme tři hlavní způsoby upgradu instalace PostgreSQL:
- pg_dump and restore
- pg_upgrade
- logická replikace
Tyto metody můžeme porovnat z hlediska robustnosti, rychlosti, požadovaných prostojů a omezení (a dalších, ale u tohoto článku se musíme někde zastavit).
pg_dump and restore je pravděpodobně nejrobustnější metoda, protože je nejvíce testovaná a používá se po desetiletí. Má také velmi málo omezení, pokud jde o to, co zvládne. Je možné konstruovat databáze, které nelze vypsat a obnovit, většinou zahrnující konkrétní vztahy závislosti na objektech, ale ty jsou vzácné a obvykle zahrnují nedoporučované praktiky.
Problém s metodou výpisu a obnovy je samozřejmě v tom, že efektivně vyžaduje odstávku po celou dobu běhu operací výpisu a obnovy. Zatímco zdrojová databáze je při běhu procesu stále čitelná a zapisovatelná, všechny aktualizace zdrojové databáze po spuštění výpisu budou ztraceny.
pg_upgrade vylepšuje proces pg_dump tím, že přesouvá datové soubory přímo, aniž byste je museli vypisovat do logické textové formy. Všimněte si, že pg_upgrade stále používá pg_dump interně ke kopírování schématu, ale ne dat. Když byl pg_upgrade nový, jeho robustnost byla zpochybňována a některé databáze upgradoval nesprávně. Ale pg_upgrade je nyní docela vyspělý a dobře otestovaný, takže s jeho používáním již z tohoto důvodu není třeba váhat. Zatímco pg_upgrade běží, databázový systém je mimo provoz. Ale je možné si vybrat, jak dlouho pg_upgrade poběží. Ve výchozím režimu kopírování se celková doba běhu skládá z času na výpis a obnovu schématu (který je obvykle velmi rychlý, pokud nemáte tisíce tabulek nebo jiných objektů) plus času na kopírování datových souborů, který závisí na jak velká je databáze (a I/O systém, souborový systém atd.).
V režimu volitelného propojení jsou datové soubory místo toho pevně propojeny s novým datovým adresářem, takže čas je pouze časem k provedení krátké operace jádra na soubor namísto kopírování každého bajtu. Nevýhodou je, že pokud se při upgradu něco pokazí nebo se budete muset vrátit ke staré instalaci, tato operace vaši starou databázi zničí. (Pracuji na nejlepším řešení z obou světů pro PostgreSQL 12 pomocí reflinků nebo operací klonování souborů na podporovaných souborových systémech.)
Logická replikace je nejnovější z této řady, takže bude pravděpodobně nějakou dobu trvat, než se vyřeší chyby. Pokud nemáte čas prozkoumávat a zkoumat, možná to teď není správná cesta. (Lidé samozřejmě k upgradu PostgreSQL používají další řešení logické replikace, která nejsou jádrem, jako je Slony, Londiste a pglogical po mnoho let, takže s principy existuje mnoho zkušeností, ne-li s podrobnostmi.)
Výhodou použití logické replikace k upgradu je to, že aplikace může nadále běžet proti staré instanci, zatímco probíhá synchronizace dat. Při přepínání klientských připojení musí dojít pouze k malému výpadku. I když je tedy upgrade pomocí logické replikace pravděpodobně pomalejší od začátku do konce než použití pg_upgrade v režimu kopírování (a rozhodně pomalejší než použití režimu pevných odkazů), na tom příliš nezáleží, protože skutečný výpadek může být mnohem kratší.
Všimněte si, že logická replikace aktuálně nereplikuje změny schématu. V tomto navrhovaném postupu upgradu je schéma stále zkopírováno přes pg_dump, ale následné změny schématu se nepřenášejí. Upgrade s logickou replikací má také několik dalších omezení. Některé operace nejsou zachyceny logickou replikací:velké objekty, TRUNCATE, změny sekvence. Řešení těchto problémů probereme později.
Pokud máte nějaké fyzické pohotovostní režimy (a pokud ne, proč ne?), existují také určité rozdíly, které je třeba zvážit mezi metodami. U obou metod je třeba vytvořit nové fyzické pohotovostní režimy pro upgradovanou instanci. S výpisem a obnovením a také s logickou replikací je lze zavést před zahájením upgradu, takže pohotovostní režim bude většinou připraven po dokončení počáteční synchronizace obnovení nebo logické replikace, s výhradou zpoždění replikace.
S pg_upgrade musí být nové pohotovostní režimy vytvořeny po dokončení upgradu primárního. (Dokumentace pg_upgrade to popisuje podrobněji.) Pokud spoléháte na vysokou dostupnost fyzických pohotovostních režimů, měly by být pohotovostní režimy na svém místě před přepnutím na novou instanci, takže nastavení pohotovostních režimů by mohlo ovlivnit vaše celkové výpočty časování.
Ale zpět k logické replikaci. Zde je návod, jak lze provést upgrade pomocí logické replikace:
0. Stará instance musí být připravena na logickou replikaci. To vyžaduje některá nastavení konfigurace, jak je popsáno na http://www.postgresql.org/docs/10/static/logical-replication-config.html (hlavně wal_level = logical . Pokud se ukáže, že tyto změny potřebujete provést, budou vyžadovat restart serveru. Zkontrolujte si to tedy s dostatečným předstihem. Zkontrolujte také, že pg_hba.conf na staré instanci je nastaven tak, aby přijímal připojení z nové instance. (Změna vyžaduje pouze opětovné načtení.)
1. Nainstalujte novou verzi PostgreSQL. Potřebujete alespoň serverový balíček a klientský balíček, který obsahuje pg_dump. Mnoho obalů nyní umožňuje instalaci více verzí vedle sebe. Pokud používáte virtuální počítače nebo cloudové instance, stojí za to zvážit instalaci nové instance na nového hostitele.
2. Nastavte novou instanci, tj. spusťte initdb. Nová instance může mít jiná nastavení než stará, například národní prostředí, velikost segmentu WAL nebo kontrolní součet. (Proč nevyužít této příležitosti k zapnutí kontrolních součtů dat?)
3. Než spustíte novou instanci, možná budete muset změnit některá nastavení konfigurace. Pokud instance běží na stejném hostiteli jako stará instance, musíte nastavit jiné číslo portu. Přeneste také všechny vlastní změny, které jste provedli v postgresql.conf na vaší staré instanci, jako je nastavení paměti, max_connections , atd. Podobně vytvořte pg_hba.conf nastavení vhodné pro vaše prostředí. Obvykle můžete začít zkopírováním souboru pg_hba.conf soubor ze staré instance. Pokud chcete používat SSL, nastavte to nyní.
4. Spusťte novou (prázdnou) instanci a zkontrolujte, zda funguje k vaší spokojenosti. Pokud nastavujete novou instanci na novém hostiteli, zkontrolujte v tomto okamžiku, že můžete vytvořit databázové připojení (pomocí psql) z nového hostitele do staré instance databáze. Budeme to potřebovat v následujících krocích.
5. Zkopírujte definice schématu pomocí pg_dumpall. (Nebo to můžete udělat pomocí pg_dump pro každou databázi zvlášť, ale pak nezapomeňte na globální objekty, jako jsou role.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Žádné změny schématu po tomto bodě nebudou migrovány. Ty bys musel zvládnout sám. V mnoha případech stačí změnit DDL na oba hostitele, ale spouštění příkazů, které mění strukturu tabulky během upgradu, je pravděpodobně příliš náročné.
6. V každé databázi ve zdrojové instanci vytvořte publikaci, která zachycuje všechny tabulky:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Logická replikace funguje v každé databázi samostatně, takže je potřeba ji v každé databázi opakovat. Na druhou stranu nemusíte upgradovat všechny databáze najednou, takže můžete provádět pouze jednu databázi nebo dokonce některé databáze neupgradovat.
7. V každé databázi v cílové instanci vytvořte předplatné, které se přihlásí k odběru právě vytvořené publikace. Ujistěte se, že zdrojová a cílová databáze správně odpovídají.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Nastavte parametry připojení podle potřeby.
8. Nyní počkejte, až předplatná zkopírují počáteční data a plně dohoní vydavatele. Počáteční stav synchronizace každé tabulky v předplatném můžete zkontrolovat v systémovém katalogu pg_subscription_rel (hledejte r =připraveno ve sloupci srsubstate ). Celkový stav replikace lze zkontrolovat v pg_stat_replication na odesílající straně a pg_stat_subscription na přijímající straně.
9. Jak bylo uvedeno výše, změny sekvence se nereplikují. Jedním z možných řešení je zkopírovat sekvenční hodnoty pomocí pg_dump. Výpis aktuálních sekvenčních hodnot můžete získat pomocí něčeho takového:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(To předpokládá, že všechny názvy sekvencí odpovídají *_seq a tomuto názvu neodpovídají žádné tabulky. Ve složitějších případech můžete také jít cestou vytvoření úplného výpisu a extrahování sekvenčních dat z obsahu výpisu.)
Vzhledem k tomu, že se sekvence mohou při tomto postupu posouvat, možná zrušte soubor seq-data.sql soubor, abyste přidali trochu volnosti k číslům.
Poté obnovte tento soubor do nové databáze pomocí psql.
10. Showtime:Přepněte aplikace na nové instance. To vyžaduje určité přemýšlení předem. V nejjednodušším scénáři zastavíte své aplikační programy, změníte nastavení připojení a restartujete. Pokud používáte proxy připojení, můžete tam přepnout připojení. Můžete také přepínat klientské aplikace jednu po druhé, možná si věci trochu otestovat nebo snížit zátěž nového systému. To bude fungovat, pokud aplikace stále ukazující na starý server a ty, které ukazují na nový server, neprovádějí konfliktní zápisy. (V takovém případě byste provozovali multimaster systém, alespoň na krátkou dobu, a to je další řád složitosti.)
11. Po dokončení upgradu můžete zrušit nastavení replikace. V každé databázi v nové instanci spusťte
DROP SUBSCRIPTION s_upgrade;
Pokud jste již vypnuli starou instanci, toto se nezdaří, protože se nebude moci dostat na vzdálený server a zrušit replikační slot. Podívejte se na manuálovou stránku DROP SUBSCRIPTION, jak v této situaci postupovat.
Publikace můžete také upustit ve zdrojové instanci, ale to není nutné, protože publikace neuchovává žádné zdroje.
12. Nakonec odstraňte staré instance, pokud je již nepotřebujete.
Některé další komentáře k zástupným řešením věcí, které logická replikace nepodporuje. Pokud používáte velké objekty, můžete je přesunout pomocí pg_dump, samozřejmě pokud se nezmění během procesu upgradu. To je významné omezení, takže pokud jste náročným uživatelem velkých objektů, pak tato metoda nemusí být pro vás. Pokud vaše aplikace během procesu upgradu vydá TRUNCATE, tyto akce nebudou replikovány. Možná můžete svou aplikaci vyladit, abyste tomu zabránili po dobu upgradu, nebo můžete místo toho nahradit DELETE. PostgreSQL 11 bude podporovat replikaci TRUNCATE, ale to bude fungovat pouze v případě, že zdrojová i cílová instance jsou PostgreSQL 11 nebo novější.
Několik závěrečných poznámek, které se skutečně týkají všech upgradů:
- Aplikace a všechny databázové klientské programy by měly být před uvedením do výroby otestovány proti nové hlavní verzi PostgreSQL.
- Za tímto účelem byste měli také otestovat postup upgradu před jeho spuštěním v produkčním prostředí.
- Zapište si věci nebo lépe skriptujte a co nejvíce automatizujte.
- Ujistěte se, že vaše nastavení zálohování, monitorovací systémy a všechny nástroje a skripty údržby jsou během procesu upgradu vhodně upraveny. V ideálním případě by měly být na místě a ověřeny před provedením přechodu.
S ohledem na to vám přeji hodně štěstí a podělte se o své zkušenosti.