Minulý týden jsem byl na Nordic PGDay 2018 a měl jsem docela dost rozhovorů o nástroji, který jsem napsal, konkrétně pglupgrade k automatizaci upgradů hlavních verzí PostgreSQL v nastavení replikačního clusteru. Byl jsem docela rád, že to bylo slyšet a někteří další lidé v různých komunitách hovořili na setkáních a jiných konferencích o upgradech téměř nulových prostojů pomocí logické replikace. Vzhledem k tomu, že existuje přednáška, kterou jsem přednesl na PGDAY'17 Russia, PGConf.EU 2017 ve Varšavě a naposledy na FOSDEM PGDay 2018 v Bruselu, myslel jsem si, že je lepší vytvořit příspěvek na blogu, aby byla tato prezentace dostupná lidem, kteří by mohli nedorazí na žádnou z výše uvedených konferencí. Pokud byste se chtěli přímo zúčastnit přednášky a přeskočit čtení tohoto příspěvku na blogu, zde je váš odkaz:Automatizované upgrady PostgreSQL clusterů v cloudu s téměř nulovým výpadkem
Hlavní motivací vývoje tohoto nástroje bylo navrhnout řešení, které minimalizuje prostoje během upgradů velkých verzí, které bohužel postihují téměř každého, kdo používá PostgreSQL. V současné době nemáme nástroj, který by uživatelům PostgreSQL umožňoval upgradovat jejich databáze bez prostojů, a je to zjevně problém pro mnoho uživatelů, zejména pro firmy. A pokud máme vyřešit problém upgradu, měli bychom uvažovat o více než jednom serveru (od nynějška bude označován jako cluster), jednoduše proto, že jen jeden databázový server již mnoho lidí nepoužívá. Nejběžnějším scénářem je nastavení replikace fyzického streamování buď pro účely vysoké dostupnosti, nebo škálování čtených dotazů.
Upgrade databáze
Než se ponoříme do řešení, pojďme diskutovat o tom, jak upgrady databází obecně fungují. Existují čtyři hlavní možné přístupy k upgradům databáze:
- Prvním přístupem by bylo, aby databáze zachovaly svůj formát úložiště stejný nebo alespoň kompatibilní napříč verzemi. To je však těžké dlouhodobě zaručit, protože nové funkce mohou vyžadovat změny ve způsobu ukládání dat nebo přidání dalších informací o metadatech, aby správně fungovaly. Výkon se také často zlepšuje optimalizací datových struktur.
- Druhým přístupem je vytvořit logickou kopii (dump) starého serveru a načíst ji na nový server. Toto je nejtradičnější přístup, který vyžaduje, aby starý server během procesu nepřijímal žádné aktualizace a vede k prodlouženým výpadkům hodin nebo dokonce dní ve velkých databázích.
- Třetí možností je převést data ze starého formátu do nového. To lze provést buď za chodu, když nový systém běží, ale způsobí to penalizaci výkonu, kterou je těžké předvídat, protože to závisí na vzorcích přístupu k datům, nebo to lze provést offline, když jsou servery mimo provoz, což opět způsobí prodloužení prostoje (ačkoli často kratší než druhá metoda).
- Čtvrtou metodou je použití logického výpisu pro ukládání a obnovu databáze a zachycování změn, k nimž mezitím dojde a po dokončení počáteční obnovy je logicky replikují do nové databáze. Tato metoda vyžaduje orchestraci několika komponent, ale také zkracuje dobu, po kterou databáze nemůže odpovídat na dotazy.
Metody upgradu v PostgreSQL
Upgrady PostgreSQL lze spojit se čtyřmi metodami uvedenými výše. Například menší verze PostgreSQL, které neobsahují nové funkce, ale pouze opravy, nemění stávající formát dat a vyhovují prvnímu přístupu. Pro druhý přístup PostgreSQL poskytuje nástroje nazvané pg_dump a pg_restore, které provádějí logické zálohování a obnovení. Existuje také nástroj pg_upgrade (byl to modul contrib a přesunul se do hlavního stromu v PostgreSQL 9.5), který provádí offline (servery neběží) převod starého datového adresáře na nový, což se hodí do třetí možnosti. Pro čtvrtý přístup existují řešení založená na spouštění třetích stran, jako je Slony, pro upgrade, ale mají několik výhrad, kterým se budeme věnovat později.
Tradiční metody upgradu mohou pouze upgradovat primární server, zatímco replikované servery musí být následně přestavěny (offline konverze) . To vede k dalším problémům s dostupností i kapacitou clusteru, čímž se efektivně prodlužuje vnímaná prostoje databáze z pohledu aplikací i uživatelů. Logická replikace umožňuje replikaci dokud je systém v provozu a testovací úsilí lze mezitím zvládnout (online konverze) .
Existují různé metody upgradu použitelné pro různá prostředí. Například pg_dump umožňuje upgrade z velmi starých verzí (tj. 7.0) na nejnovější verze, takže pokud používáte starou verzi PostgreSQL, nejlepší metodou je použití pg_dump/restore (a je lepší to udělat hned!). Pokud je vaše PostgreSQL verze 8.4 a novější můžete použít pg_upgrade . Pokud náhodou používáte PostgreSQL 9.4 a novější to znamená, že máte v jádru „Logické dekódování“ a můžete použít pglogic rozšíření jako prostředek upgradu. A konečně, pokud používáte PostgreSQL 10 , budete mít možnost upgradovat svou databázi na PostgreSQL 11 a novější (jakmile budou k dispozici) pomocí in-core „Logical Replication“ (yay!).
Logická replikace pro upgrady
Kde je myšlenka upgradovat PostgreSQL pomocí logické replikace pochází z? Jasně, pglogický netvrdí otevřeně účel upgradu jako pg_upgrade ano (toto byl jeden argument proti pglogic na konferenčním večírku ), to však neznamená, že tento nástroj nemůžeme použít k upgradům. Ve skutečnosti, když byl pglogical navržen, upgrady s téměř nulovými prostoji byly považovány za jeden z očekávaných případů použití vývojáři rozšíření.
Na rozdíl od fyzické replikace, která zachycuje změny nezpracovaných dat na disku, logická replikace zachycuje logické změny jednotlivých záznamů v databázi a replikuje je. Logické záznamy fungujív hlavních vydáních , proto lze k upgradu použít logickou replikaci z jednoho vydání do druhého. Myšlenka použití logické replikace jako prostředku upgradu verze není zdaleka nová, spouštěcí nástroje replikace prováděly upgrady logickým způsobem zachycováním a odesíláním změn pomocí spouštěčů (protože spouštěče mohou fungovat i bez ohledu na verze databáze! ).
Pokud můžete použít řešení replikace založená na spouštěcích pro upgrady s minimálními prostoji, proč byste místo toho měli upřednostňovat logickou replikaci? V mechanismu založeném na spouštěči jsou všechny změny zachyceny pomocí spouštěčů a zapsány do tabulek fronty. Tento postup zdvojnásobuje operace zápisu, zdvojnásobuje soubory protokolu a zpomaluje systém, protože všechny změny je třeba zapsat dvakrát; výsledkem je více diskových I/O a zatížení zdrojového serveru. Naproti tomu logická replikace v jádru (totéž platí pro pglogické rozšíření) je postavena na logickém dekódování. Logické dekódování je mechanismus, který extrahuje informace ze souborů WAL do logických změn (INSERT/UPDATE/DELETE). Protože se data z mechanismu WAL používají k dekódování transakčních protokolů, nedochází k žádnému zesílení zápisu jako v případě řešení replikace založených na spouštěči, proto tato metoda funguje lépe . Výsledkem je, že řešení založená na logickém dekódování mají jednoduše menší dopad na systém než řešení založená na spouštění.
Závěr
V tomto úvodním příspěvku jsem chtěl poskytnout nápad, proč bychom měli zvážit použití logické replikace, abychom dosáhli minimálních prostojů během upgradů hlavních verzí. V podrobnostech architektury a implementace nástroje budeme pokračovat v nadcházejícím příspěvku.