PostgreSQL 9.6 byl právě vydán a většina uživatelů postgresu se začne ptát, jak upgradovat na novou hlavní verzi. Tento příspěvek má za cíl ukázat různé postupy pro upgrade vašeho PostgreSQL serveru.
Upgrade na novou hlavní verzi je úkol, který má vysoký poměr přípravy k celkovému času provádění. Konkrétně při přeskočení vydání uprostřed, například při přechodu z verze 9.3 na verzi 9.5.
Vydání bodu
Na druhou stranu upgrady point release nevyžadují tolik přípravy. Obecně platí, že jediným požadavkem je restartování služby postgres. Neexistují žádné změny v základní datové struktuře, takže není třeba vypisovat a obnovovat. V nejhorším případě budete možná muset po dokončení upgradu bodové verze znovu vytvořit některé ze svých indexů.
Je velmi moudré vždy zůstat na nejnovější verzi, abyste nenarazili na známou (a pravděpodobně opravenou) chybu. To znamená, že jakmile bude k dispozici nejnovější verze, naplánujte si čas aktualizace co nejdříve.
Hlavní aktualizace vydání
Při provádění složitých úkolů, jako je tento, je dobré zvážit všechny možné možnosti, jak dosáhnout konečného výsledku.
U upgradů hlavních verzí existují tři možné cesty, kterými se můžete vydat:
- Upgradujte obnovení z logického výpisu
- Fyzický upgrade
- Online upgrade
Dovolte mi, abych každý z nich podrobně vysvětlil:
1) Upgradujte obnovu z logického výpisu
Toto je nejjednodušší ze všech možných způsobů upgradu datové struktury vašeho clusteru.
Abych to zkrátil, proces zde vyžaduje logický výpis pomocí pg_dump ze staré verze a pg_restore na čistém clusteru vytvořeném s nově nainstalovanou verzí.
Klíčové body ve prospěch použití této cesty jsou:
- Je to nejvíce testované
- Kompatibilita se vrací k verzi 7.0, takže nakonec můžete upgradovat z verze 7.x na některou z nejnovějších verzí
Důvody, proč byste se měli vyhnout použití této možnosti:
- Celkový výpadek u velkých databází může být problém, protože před spuštěním pg_dump musíte zastavit připojení pro zápis;
- Pokud je v databázi mnoho velkých objektů, pg_dump bude pomalý. I když to děláte paralelně. Obnova bude ještě pomalejší než pg_dump, když je v databázi uloženo mnoho velkých objektů;
- Před obnovením vyžaduje dvojnásobné místo na disku nebo odstranění starého clusteru;
Na serverech s několika jádry CPU je možné spouštět pg_dump paralelně pomocí adresářového formátu. Po dokončení obnovte také paralelně pomocí přepínače -j v pg_dump i pg_restore. Ale nemůžete spustit proces obnovy, dokud nebude dokončen celý výpis.
2) Fyzický upgrade
Tento druh upgradů je k dispozici od verze 9.0, aby bylo možné provádět upgrady na místě z verzí tak starých jako 8.3. Říká se jim „na místě“, protože se provádějí na stejném serveru a nejlépe ve stejném datovém adresáři.
Výhody tohoto druhu upgradů:
- Nepotřebujete místo pro další kopii clusteru.
- Prostoj je mnohem kratší ve srovnání s použitím pg_dump.
Existuje několik nevýhod:
- Jakmile spustíte novou verzi PostgreSQL, není možné se vrátit ke staré verzi (klastr bude dále fungovat pouze s novou verzí).
- Statistiky jsou po upgradu vynulovány, takže ihned po spuštění nové verze PostgreSQL je třeba provést analýzu celého clusteru.
- Během posledních let bylo v souvislosti s pg_upgrade zjištěno mnoho chyb, kvůli kterým se někteří správci databází zdráhají používat tuto metodu pro upgrade.
- Někteří lidé měli problémy s přeskočením velkého vydání, například přechodem z verze 9.2 na verzi 9.4.
- U velkých katalogů bude fungovat špatně (shluky s mnoha databázemi nebo databáze s mnoha tisíci objekty).
Můžete také spustit pg_upgrade bez možnosti –link (v tomto případě pg_upgrade vygeneruje druhou kopii na disku vašeho clusteru), takže se můžete vrátit ke staré verzi. Ztratíte však obě výše uvedené výhody.
3) On-line upgrade
Postup pro tuto metodu by byl tento:
- Nainstalujte obě verze, abyste je mohli nechat pracovat paralelně. To lze provést na stejném serveru nebo pomocí dvou fyzických serverů.
- Vytvořte počáteční kopii a replikujte změny od okamžiku, kdy jste spustili kopii na zdrojovém uzlu (to by bylo podobné počátečnímu pg_dump).
- Pokračujte v logickém opakování změn, dokud se zpoždění nebude blížit nule.
- Přesměrujte informace o připojení z aplikačního serveru pro připojení k novému serveru.
Tento typ upgradu je k dispozici od doby, kdy existovala první řešení replikace založená na spouštěči. Jinými slovy, od té doby, co jsem tu byl Slony.
Replikačním řešením založeným na spouštěčech je jedno, jakou verzi máte na jedné nebo druhé straně, protože kopíruje změny pomocí podporovaných příkazů SQL.
Doporučené nástroje replikace založené na spouštěči v pořadí, v jakém se zobrazují, jsou:
- skytools:PgQ + londiste
- Slony-I
Toto by měl být preferovaný způsob upgradu. Podívejme se na výhody použití této metody:
- Nulové prostoje!
- Skvělé také pro upgrade na novější hardware.
- Online testování clusteru s novou verzí (dotazy pouze pro čtení, jinak můžete skončit s konflikty).
- Drasticky snižuje všechna nafouknutí tabulek a indexů.
Existují určité nevýhody:
- Potřebuje dvojnásobný úložný prostor, protože musí uložit druhou kopii vašich dat.
- Jelikož je to založeno na triggerech, systém musí každou změnu zapsat dvakrát, což znamená, že na zdrojovém serveru (stará verze clusteru) bude více diskových I/O.
- Všechny tabulky musí mít primární klíč, takže replikační nástroj může individualizovat n-tice, které jsou aktualizovány nebo odstraněny
- Nereplikuje katalogové tabulky, takže nebude replikovat velké objekty.
- Základní použití nezahrnuje změny schématu. Dá se to udělat, ale ne transparentně.
Nová hranice s pglogic
Od PostgreSQL 9.4 máme logické dekódování transakčních protokolů. To znamená, že nyní můžeme dekódovat transakce z WAL a manipulovat s výstupem.
V oblasti replikace se objevil zcela nový svět možností. Spouštěče již nejsou nutné k provedení logické replikace!
To v podstatě znamená, že už nemusíte ukládat samostatnou kopii všech vložení, aktualizací a odstranění pomocí spouštěčů. Tyto operace manipulace s daty můžete získat pouze z protokolů transakcí jejich dekódováním. Pak je to nástroj, který používáte, který musí manipulovat s výstupem a odeslat jej do předplaceného downstreamového uzlu. V tomto případě je tento nástroj pglogický.
Takže, co to všechno znamená?
Pokud používáte PostgreSQL verzi 9.4 nebo 9.5 a chcete upgradovat na 9.6, můžete provést online upgrade, jako je ten podrobně popsaný výše, ale s použitím pglogical namísto jednoho z řešení replikace založené na spouštěči.
Nebudu zabíhat do podrobností, protože na toto konkrétní téma existují i jiné blogy, jako je tento od Petra Jelínka:PGLogical 1.1 packages for PostgreSQL 9.6beta1
Závěry
V závislosti na schématu vaší databáze, velikosti dat, možném prostoji, verzi aktuální instalace PostgreSQL si můžete vybrat jednu možnost před druhou nebo cokoli, co nejlépe vyhovuje.
- Pokud je vaše databáze malá a existuje vhodné okno údržby, které můžete použít, můžete se rozhodnout pro spuštění pg_dump a pg_restore. V závislosti na velikosti souboru dat existuje bod, kdy tato možnost již není proveditelná.
- Pokud máte velkou databázi (několik stovek GB nebo dokonce TB dat), budete muset hledat jiné možnosti, jako je místní upgrade pomocí pg_upgrade nebo online upgrade.
- Pokud upgradujete z verze 8.3 nebo vyšší na jakoukoli verzi 9.x, můžete použít pg_upgrade.
- U verzí starších než 8.3 se budete muset rozhodnout pro jedno z řešení logické replikace, jako je londiste nebo slony.
- Pokud máte databázi 9.4 nebo 9.5, je lepší použít pglogical.
Vždy pamatujte, že pro logickou replikaci musí mít tabulky primární klíč.
S pglogic toto pravidlo není tak přísné:Můžete replikovat tabulky pouze pro vložení. Ale pro aktualizace a mazání je stále povinné mít na stole primární klíč nebo REPLICOVOU IDENTITU.
Pokud potřebujete pomoc s upgradem databáze PostgreSQL, můžete se podívat na
služby upgradu 2ndQuadrant.