Dotaz: Upgrade PostgreSQL

[Milan Kozák]

Ahoj, řeším problém aktualizace/přenosu PostgreSQL databáze. Na stávajícím 32bit. virtuálním serveru s Debianem 5.0.10 mám PGSQL 8.13.17. Tuto bych chtěl přenést na nový virtuální 64bit server s aktuálním Debianem a PGSQL řady 9.

Jak správně postupovat? Jak celou opraci provést v co nejmensím časovém okně?

Databáze obsahuje několik desítek miliónů záznamů a má velikost cca 120GB.

Předpokládám, že nejčistší způsob bude zaktualizovat 32bit Debian, udělat pg_upgradecluster && pg_drop_cluster (což bude na pár hodin) a následně db dumpnout a naimportovat na 64bit (což bude opět na pár hodin)?

Existuje nějaký rychlejší/efektivnější způsob jak to udělat (např.: Slony)? Nějaké rady na co si dát pozor? Děkuji.

---

---

Odpovědi

[mfo]

Moja otazka je, kedze ides z 32 bit na 64. ide to tak ako si napisal? Nebude najlepsie pouzit export zo starej DB -import na novy server. Vyhody: ak sa nieco pokasle, stale mozes zapnut stary server. Mozes testovat kolko ti to bude trvat, ake chyby nastanu atd. Ak mas testovaci server. Ak nie, nezabudni na backup. ( v pripade virtualky je to len snapshot). Nezabudni si hlavne pozriet je upgrade z verzie 8.13.17 podporovany na verziu 9.XX.XX

Br, mfo.

[Milan Kozák]

Na MySQL bych to takto s klidem udělal. PostgreSQL ovšem zase až tak neznám, takže se radši ptám.V oficiální dokumentaci je jednou doporučovaný pg_dump/pg_dump_all, podruhé píšou že je lepší přecházet pomocí pg_update_cluster a potřetí že je možné použít pg_upgrade (beru-li v potaz stejnou architekturu). Vyzkoušet se samozřejmně dají všechny postupy nicméně se mi nechce - nechci generovat zvýšený load databáze (zálohováním či IO operacemi), nechci nad tím trávit desítky hodin času a navíc nevím jak bych ve finále ověřil konzistentnost dat. Proto hledám někoho, kdo se s tím už trápil a může doporučit ten správný postup.

[SPM]

Podle mě by ten upgrade neměl být potřeba. Mělo by stačit udělat dump, přenést na nový server a naimportovat. Tohle se dá i vyzkoušet bezvýpadkově (dump by neměl běh db ovlivnit). Pro zvýšení výkonu co si pamatuju se doporučovalo místo pg_dumpall použít pg_dump po db a importovat ve více threadech naráz.

[Milan Kozák]

Podle mě by to mohlo jít také, ale jak jsem psal výše - hledám zkušenosti někoho kdo to už dělal. Navíc bych rád věděl, co je rychlejší - zda-li udělat pg_update_cluster nebo pg_dump/pg_restore (případně něco zcela jiného). Předpokládám, že pg_update_cluster by měl být rychlejší (IMHO se pouze mění struktura) zato pg_dump/restore by měl trvat řádově déle kvůli vytváření indexů. Jsou to ale jen moje ničím nepodložené doměnky. Otestovat to mám problém - update_cluster bez výpadku neudělám a u pg_dumpu mi začne po chvíli lézt load tak vysoko, že db nestíhá odpovídat aplikaci v požadovaném čase.

[SPM]

s pg_update to určitě rychlejší nebude, protože po tom updatu je stejně třeba udělat dump a přenést ho na druhý server. Teoreticky by stačilo přenést jen upgradlé datové soubory, ale u rozdílných architektur mi to nepřijde jako moc dobrý nápad...

[okbob]

Existuje několik možností - 1. Postgresovou klasikou: pg_dumpall > dump; psql < dump - to je nejrobustnější a nedá se na tom co skazit, 2. pg_upgradecluster je debianí záležitost (nic o tom nevím), 3. nově pg_upgrade http://www.postgresql.org/docs/9.2/static/pgupgrade.html

Nejrychlejší je pg_upgrade - což je on-place upgrade - ale funguje to od jistých verzí - žádnou 8.13.17 neznám. A určitě to chce zálohovat! Po upgrade není jednoduchá cesta zpět.

[Milan Kozák]

Děkuji za Vaši odpověď. S verzí databáze jsem se uťukl - správně je:

portal:~# dpkg -l | grep postgresql-8
ii  postgresql-8.3                           8.3.17-0lenny1             object-relational SQL database, version 8.3

Co se týče dumpu, mám v něj také největší důvěru ale na druhou stranu tím způsobím asi největší výpadek. U pg_upgrade jsem někde na stránkách PGSQL četl že není zdaleka tak odladěný a že se příliš nedoporučuje (možná už to neplatí pro nové verze). Ani u 9 řadky to ale není úplně bezproblémů -vizte např.:

F.32.4. Limitations in Migrating from PostgreSQL 8.3

Upgrading from PostgreSQL 8.3 has additional restrictions not present when upgrading from later PostgreSQL releases. For example, pg_upgrade will not work for a migration from 8.3 if a user column is defined as:

    a tsquery data type

    data type name and is not the first column

pg_upgrade will not work if the ltree contrib module is installed in a database.

You must drop any such columns and migrate them manually.

pg_upgrade will require a table rebuild if:

    a user column is of data type tsvector

pg_upgrade will require a reindex if:

    an index is of type hash or GIN

    an index uses bpchar_pattern_ops

Also, the default datetime storage format changed to integer after PostgreSQL 8.3. pg_upgrade will check that the datetime storage format used by the old and new clusters match. Make sure your new cluster is built with the configure flag --disable-integer-datetimes.

Marně očekávám, že se zde objeví někdo, kdo obdobnou operaci prováděl například pomocí Slony, kde to snad jde udělat de-facto bez výpadku. V každém případě díky za připomínky všem diskutujícím.

[okbob]

Tak jako tak doporučuji si upgrade vyzkoušet - někde bokem - mezi 8.3 a 9.1 je několik nekompatibilit a také byly odstraněny některé deprecated funkce. Takže si vyzkoušejte upgrade, a vyzkoušejte si, jak Vám pojede aplikace s novou verzí databází

[okbob]

Import dumpu se da urychlit nastavenim

fsync=off
maintenance_work_mem=256MB

Ale tohle je pouze pro import! - v pripade havarie hrozi poskozeni db

[Hlipa]

Pavle bod 3) nefunguje kvuli binarni nekompatibilite 32bitove a 64bitove verze postgreSQL. Nelze totiz obecne pustit 64bitovou binarku nad databazi, ktera byla vytovorena 32bitovou binarkou.

[dik]

Me se osvecil tento postup:

1. rsyncnu si mezi oldserver a newserver /var/lib/pgsql (databáze jede,pouziju vhodny --bwlimit ať nepřetížím IO na oldserver)
2. zastavím databázi a udělám finální poslední rsync - mám přenesené konzistentní soubory a je to hned)
3. na novém server použíju pg_upgrade s volbou hardlink (nic se nekopíruje, je to hned)
4. spustím novou databázi a du na pivo

nicméně z důvodu lenosti a pokud to okolnosti dovolí nejraději používám pg_dumpall přes ssh pipu na nový stroj Dik

[Milan Kozák]

Díky za reakci. Co se týče kopie databáze, tak rsyncem to takto u "větších" DB nejde, protože se poměrně rychle mění velké množství dat. U mě by musel být i při záloze na disk vyplý PG několik minut. Vyřešil jsem si to tak, že databázi mám na oddílu s LVM. Stačí ji na vteřinu zastavit, udělat snapshot a následně data rsyncovat. Předpokládám ale, že až bude databáze skutečně velká, nebude možné tento postup z výkonostních důvodů používat. U pg_upgrade jsem parametr link přehlédl - díky za něj - nicméně to IMHO neřeší problém se změnou architektury. Popravdě ani moc nevěřím, že to bude hned - změna schématu (při povýšení) určitě nějaký čas zabere, ale určitě to vyzkouším.

[Heron]

Na LVM snapshot pozor. Zapis je potom nehorazne pomaly (v mem domacim mereni az 10x). Tak aby sis tim nakonec neodstavil app, kterou chces proti odstaveni chranit.

Z me praxe plyne, ze je casto lepsi a rychlejsi udelat dobre pripravenou planovanou odstavku, nez potom resit rozbity stav po nejake partyzanske akci. Proto se primlouvam za overenou cestu dump a restore.

[dik]

...tak tak, výkon lvm snapshotu je naprosto zoufalý, (prý na tom RH pracuje), snapshot na btrfs je jiné kafe, ale do produkce se zatím nehodí, maximálně tak na backup server.

Varianta s rsync je naprosto bezpečná rychlá , prostě si data předopíruješ ze živého serveru a finálně přenášíš jen malé rozdíly...

Dump,restore je jistota..

Dik

[Milan Kozák]

...tak tak, výkon lvm snapshotu je naprosto zoufalý, (prý na tom RH pracuje),

Toho jsem si vědom a dokonce jsem to v tom odstavci napsal. Pro mě je to zatím v pohodě. Zálohy se dělají v noci, kdy v aplikaci pracuje minimum lidí. Navíc rsync snapshotu trvá v průměru 130minut (a pak ji automaticky mažu). Výkonově zde zatím problém nemám.

snapshot na btrfs je jiné kafe, ale do produkce se zatím nehodí, maximálně tak na backup server.

Ono BTRFS se s PGSQL vůbec nemá (nemělo) rádo. Když jsem ho naposledy testoval tak se mi téměř trojnásobně snížil výkon databáze

Varianta s rsync je naprosto bezpečná rychlá , prostě si data předopíruješ ze živého serveru a finálně přenášíš jen malé rozdíly...

Vidím to stejně. Ještě udělám pár testů na nečisto a pak poreferuji jak jsem dopadl...

[ZAH]

Takže jsem asi hotov. Na testovacím stroji se mi nejvíce osvědčila metoda pomocí klasického pg_dump a psql. Abych data nemusel komprimovat a přenášet, pomohl jsem si netcatem. Jelikož jsem to dělal v rámci dvou virtuálů na stejném stroji doma na stole, neřešil jsem bezpečnost. V ostatních případech by bylo záhodno vyměnit netcat například za ssh.

Na novém virtuálním serveru (netcat traditional):
nc -l -p 12345 | psql -f - fueltrack

Na starém virtuálním serveru (openbsd netcat):
pg_dump databáze | nc 10.0.0.2 12345

Rychlost v pohodě, data konzistentní, takže radost. Děkuji všem a diskusi můžeme uzavřít.