Názory k článku Upgrade databáze z PostgreSQL 9.6 na verzi 13 v doménovém registru
-
Nelze to provozovat v rezimu mixed-version? Tj. mit v clusteru ruzne verze a postupne je upgradovat? (neco na zpusob LTO pasek, kde je prekryv podpory 1 generace na zapis a dvou na cteni - nebo tak nejak).
A podle popisu jak ctu - tak postacilo opravdu provest spravnou instrumentaci (dle sluzeb co pouzivaji db) - a upgrade samotne databaze byl bez problemu?
-
Fyzická streaming replikace umí jenom stejnou verzi, protože formát WALu se mezi verzemi mění a replikace fakticky provádí recovery (tj. aplikuje WAL). Čili cílový stroj by dostával formát 9.6, ale binárky by měl 13 a to bohužel nejde dohromady :-(
Existuje i tzv. logická replikace, kdy se WAL dekóduje na logické operace, a to samozřejmě mezi verzemi funguje. Ale jsou tam různá omezení (zejména ve starších verzích jako 9.6) a je to složitější na nasazení - u systémů kde je kritické naprosto minimalizovat výpadek / maximalizovat uptime se to používá, ale pokud je akceptovatelná krátká outage pro dump/restore neb pg_upgrade tak je to asi zbytečná práce.
-
@upgrade
Mozem potvrdit, ten upgrade je malokedy problematicky (zvedsa ak nie su naistalovane potrebne extensions).
@replikacia
Pre Write-Ahead Log Shipping je nutne aby major vezie boli rovnake. Je to tym ze WAL je primarne pouzity pre iny ucel.
Pre logicku replikaciu je vraj mozne aby master a slave boli v roznych verziach, ale odskusane to nemam. Je samozrejme nutne aby neboli pouzite veci ktore ta nizsia verzia nepozna.
-
Dobrý den,
pokud se nepletu, pak logická replikace je dostupná až od PostgreSQL verze 10. Každopádně na logickou replikaci plánujeme přejít, už teď nás ta streaming replikace v některých případech omezuje.
>> “A podle popisu jak ctu - tak postacilo opravdu provest spravnou instrumentaci (dle sluzeb co pouzivaji db) - a upgrade samotne databaze byl bez problemu?”
Ano, přesně tak.
VS
-
S logickou replikací je to trochu složitější - máte pravdu že "zabudovaná" logická replikace je až v PostgreSQL 10, tj. od té verze jde udělat CREATE PUBLICATION / SUBSCRIPTION atd.
Ale už od verze 9.4 je tam potřebná infrastruktura na dekódování WALu pomocí pluginů, a existují externí projekty které právě umí logickou replikaci už před 10 - pglogical, debezium, wal2json. Není to tak samozřejmě tak pohodlné jako ta zabudovaná replikace, ale zase to může dělat i věci které ta zabudovaná neumí.
-
> Utilita initdb, která se používá k inicializaci nového databázového clusteru je již standardně povoluje. A na tomto zjištění právě skončil upgradovací skript. Naštěstí bylo řešení jednoduché, v novém databázovém clusteru stačilo checksumy dodatečně vypnout
Tohle si myslím že není přesné - initdb zcela jistě checksumy automaticky nezapíná, a apt balíky tohle chování myslím nijak nemodifikují. Čili je otázka proč tam ty checksumy byly zapnuté ...
> postgres@db> reindexdb -j 24 fred
Jo, je pravda že indexy mohou být rozbité kvůli upgrade glibc collations, ale týká se to čistě jenom indexů nad řetězci. Čili indexy nad ostatními datovými typy (čísla, UUID, ...) není třeba reindexovat, což je typicky většina.
-
Reindexovať tesne pred VACUUM FULL je zbytočné. V rámci VACUUM FULL sa to udeje znovu - nová tabuľka je organizovaná inak, pôvodné indexy by nešli použiť. Popísané to je tu:
https://www.postgresql.org/docs/13/progress-reporting.html#CLUSTER-PROGRESS-REPORTING
VACUUM FULL tiež nepoužíva indexy na vstupe (na rozdiel od napr. CLUSTER), takže odpadá problém s nekorektnými výstupmi na základe indexov.25. 1. 2022, 08:06 editováno autorem komentáře
-
-
Dobrý den,
Vámi uváděný způsob je samozřejmě možný. Nicméně jsme radeji volili variantu čisté instalace, obecně tak postupujeme ve všech případech povýšení major verze operačního systému. Jednak si tím trochu vyčistí různý “nepořádek” na filesystému a jednak je ta čistá instalace OS velmi rychlá záležitost. Kompletní nastavení nového systému a konfigurace databáze je pak otázka již připraveného Ansible playbooku a jedné kávy :-)
A jak zde již bylo uvedeno, v čase prací na databázích (poslední kvartál roku 2021) nemělo smysl instalovat Ubuntu 20.04, jehož podpora skončí dříve než v případě Debian 11. Museli bychom zkrátka “brzy” řešit další aktualizaci OS. Tím pádem to nebylo možné provést způsobem “ do-release-upgrade -d”.
VS
-
Ona ta čistá instalace se v případě nasazeného Ansible prostě vyplatí už kvůli testům toho ansible playbooku - obsahuje vše podle reálného stavu serveru? Dokáže zreplikovat nastavení i v novější verzi/jiné distribuci zcela korektně? Počítá playbook s opravdu čistým štítem (např. vytvoření souboru v neexistujícím adresáři, který na starém serveru je přeci odjakživa)?
Zvláště v kombinaci s nějakou automatikou pro instalaci je to opravdu řešení na dvě kávičky.
-
Ten náš Ansible playbook počítá opravdu se vším, např. s rúznými podpůrnými scripty, metrikami pro pgwatch2 monitoring apod.
Navíc vzhedem k tomu, že databáze registru běží celkem v devíti instancích (3x produkce, 3x interní test, 2x adminský test a 1x veřejný test), pak bez Ansible s kompletní konfigurací to není možné rozumně udržet konzistentní.
VS
-
Prekvapuje me, jak rychle se nacte dump cele databaze zpet. Mame na Postgresu informacni system, jeho databaze ma cca jen 20GB a jeji nacteni trva nekolik hodin. Vim ze na to mozna nejde snadno odpovedet, ale nemame vhodny postup, nebo je rychlost dana strukturou dat? Nemame Postgres jen jako uloziste radku, ale obsahuje integritni omezeni, trigery, procedury.... a kontroly toho vseho mozna nacteni zpomaluji. Muze to byt?
-
Určitě bude záležet, jak velké indexy v databázi jsou, zda-li máte plotnové disky nebo SSD a také na míře paralelismu při obnově. Obecně tedy hodně záleží na HW. Produkční servery registru mají vždy 2x Intel Gold procesory nebo ekvivalent v AMD, 128GB RAM a výhradně SSD disky. Ty jsou (v RAID svazcích) používány zvlášť pro “/var/lib/postgres”, zvlášt pro XLOGy a zvlášt pro OS+backupy. Hodně také záleží na tom, abyste dump měli a jiné partišně, než datové soubory databáze.
-
Není to normální - těžko říct, v čem je problém, ale v uložených procedurách a constrainech to nebude. To se aktivuje až nakonec (Postgres důvěřuje svému exportu). Vzpomínám si, že před 15roky 50GB databáze se restorovala 2 hodiny (včetně dumpu).
Co může být problém - buďto málo RAM, pomalé IO, možná používáte GIN indexy, které jsou náročnější na vytvoření. Zkuste restore na jiném železe, případně se podívejte, co vám restore vypisuje a na čem to vázne. 20GB bych čekal do půl hodiny.
-
To musi byt v HW, resp. I/O subsystemem (bud fyzickym nebo SW). To je zaklad rychlosti backup/restore. Nemam zkusenosti s Postgresem, ale napriklad s Oraclem a Informixem a tam je rychlost I/O pro backup/restore klicova (pochopitelne).
Mam napriklad "all flash" diskove pole pripojene k hostu pomoci 16 Gbit fibre channel (SAN), tak mi zaloha 3 TB databaze bezi 1h20min (a to jeste v ramci optimalizace hrnu backup via "pigz -4 -p 16" (paralelni gzip na 16 CPU) a az pak ukladam na disk (jina array nez kde lezi databaze).
Restore takove zalohy pak bezi necele 4h, ale jsem limitovan siti (obnovuje se napr. testovaci instance na jinem serveru, nez kde lezi ten backup z primaru). Takze byt to lokalne, realne budu nekde kolem 3h odhaduji.
V mem vyse uvedem pripade pak dokaze jet I/O subsytem serveru (AIX/Linux) ve vyssi stovkach MB/s, na serveru s NAND flash disky i pres 1 GB/s.
-
Jo, těžko říct bez podrobnějších informací o verzi a konfiguraci Postgresu, hardware, jak přesně se dumpuje/restoruje, atd. Ideální by bylo při tom restore zapnout logování trvání pro všechny přípazy a podívat se na čem to drhne.
Pro srovnání, na "malém" stroji který používám pro testování (4 jádra, 8GB RAM, SSD) trvá načtení 16GB pgbench databáze cca 2 minuty, na větším stroji se 120GB generuje cca 15 minut. Jasně, je to jednoduchá strutura, nejsou tam FK, ale prostě 20GB to musí dát za pár minut, pokud stíhají disky.
-
HW mame odpovidajici, to dneska neni problem poridit, stejne tak (snad) nastaveni. Disky to stihaji bez problemu, mame 3x vice RAM nez je velikost te databaze na disku, takze se pouziva spis jen cache a IO jdou minimlani. Dela to velkou zatez na CPU. Ja necekam presnou odpoved, potrebujeme to ta jednou za rok, coz neni problem. Pravdepodobne je to strukturou databaze, protoze ten informacni system je napsany prakticky cely v tom postgresu a jeho klient je jen "browser". DIky za napady.
-
Bez přístupu k tomu systému, tak vám nikdo nic nemůže říct. Křišťálovou kouli nevedeme. pg_restore má flag --verbose, zkuste ho použít a měřit si, kdy, co vypisuje. Ale tím, že je ten systém napsaný ve storkách to nebude. Ty se načtou během několika málo sec. Na internetu můžete najít kontakt na mne (Pavel Stěhule), a pokud mi umožníte ssh na ten db server, tak vám řeknu, čím to je, ale podle vašeho popisu vůbec netuším, čím by to mohlo být.
-
Mam uz za sebou desitky aktualizaci postgre a musim rict, ze je to temer bezproblemovy (ale nasi vyvojari pouzivaji jen omezene moznosti psql). Kazdopadne, pg_upgrade pouzivam bez "--link", pro mne je to jistejsi, kdyby se neco rozbilo, nez resit hardlinkovanou databazi. Samozrejme, vyzaduje to cas a kapacitu disku...
ČLÁNKY DO MAILU