Zálohování a obnova PostgreSQL metodou PITR (point in time recovery) (diskuse)

[Käyttäjä 11133]

Rychlost obnovy z recovery logů je zhruba rychlost LTO4 páskové mechaniky - 120MB/s, ale u velkých databází je to prostě stále moc pomalé, pokud se dělá full backup jednou týdně (říkáš jí base záloha), tak u rozumné databáze může jít velikost logů až do velikosti terabytů.

A zálohování databázových serverů přes VMware (nebo jinými VM-based) snapshoty je prostě zlo... Od kdy to výrobce databáze podporuje? Leda že byste nastartovali base zálohu, udělali VM-based snapshot a pak ukončili base zálohu, pak se jedná o stejnou formu konzistence, jako u uvedeného archivního režimu.

[Heron]

Pro vetsi velikosti DB existuji zase jine techniky, treba replikace. Jak pise nekdo dole, z tohoto zpusobu zalohovani se snadno udela i hot_standby. Dneska uz je k disposizi i streaming replication.

Zalohovani pomoci snapshotu "podporuje" kazda db, ktera splnuje ACID. Snapshot se z principu dela mezi dvema fsync (a flush) souboroveho systemu a pro db to nepredstavuje problem. Je to totez, jako recovery po vypadku napajeni. Postgres si precte cely wal a jede se dal.

[Lampa]

No defacto hotstanby je asynchronni streaming replication, da se samozrejme nastavit i synchronni, ale na pomale lince je to trosku problem pri velkem poctu aktualizaci

[Pavel Francírek]

Plét si zálohování s replikací se vám může pěkně vymstít. Záloha je to, co vás ochrání i v případě DROP DATABASE CASCADE. Replikace to není.

[Heron]

To ale nikdo netvrdí . Replikace je další místo, kde lze s DB něco dělat, relativně nezávisle na hlavním serveru. Od velkého logického dumpu počínaje (takhle se to používá, bohužel s velkým rizikem poškození dat, na Mysql), po kompletní konzistentní zálohu serveru na pásku konče. Tedy ano, replikace sama o sobě není záloha, ale může ji usnadnit.

[Käyttäjä 11133]

Zalohovani pomoci snapshotu "podporuje" kazda db, ktera splnuje ACID.

To že má něco fungovat, automaticky neznamená, že až nastane problém, že ti vendor databáze neřekne, že si idiot, a že pokud chceš jeho pomoc s problémem, tak si musíš pořídit professional services s cenou 2500EUR/den.

To máš jako s provozem Oracle DB pod VMware, spoustě lidem to funguje, spousta firem to provozuje, ale jakmile nastane problém, můžou si stěžovat leda na lampárně a ne u Oracle.

[Heron]

To že má něco fungovat, automaticky neznamená, že až nastane problém, že ti vendor databáze neřekne, že si idiot, a že pokud chceš jeho pomoc s problémem, tak si musíš pořídit professional services s cenou 2500EUR/den.

Jinými slovy si připlatit za funkci, která má fungovat by default a kterou ten produkt deklaruje.

To máš jako s provozem Oracle DB pod VMware, spoustě lidem to funguje, spousta firem to provozuje, ale jakmile nastane problém, můžou si stěžovat leda na lampárně a ne u Oracle.

Což je další bod pro OpenSource. Většinou to funguje, když ne, tak se to považuje za bug, který se opraví. A když ani to ne, tak je to alespoň zadarmo. S drahým nefunkčním komerčním software jsem si za poslední rok užil své, ale on tom třeba někdy do blogu.

[TomasVondra]

Ne zcela rozumím v čem vidíte problém.

To že vám vendor hodí na hlavu zbastlené řešení které se chová nestandardně není nijak divné. Bohužel s proprietárními řešeními máme dost malou možnost odhalit kde ta chyba vlastně je a hodit to na hlavu správnému vendorovi, a oni se do investigace rozhodně hrnout nebudou. Alespoň pokud jim zaplatíte.

Jinak snapshotting na úrovni filesystému se pro zálohování DB běžně používá - například na AWS jsou snapshoty EBS celkem oblíbené (a spolehlivé), to samé se dá říct o LVM snapshotech (i když tam jsou často pozorované dopady na výkon).

[Käyttäjä 11133]

Ale jinak pěkný článek, brzo se mi bude hodit, když ho trošku upravím, alespoň to nemusím studovat (znovu, jednou už jsem backup scripty pro PostgreSQL psal, ale dávno jsem to zapoměl :) ).

[Lampa]

Nedavno jsem resil neco podobneho, ale je na to vyhrazeny server, takze jsem pouzil hot_standby rezim.

Kopiruji se logy na cilovy server, tam se automaticky zpracuji (postgresql si to hlida). Dalsi vyhodou je ze standby db je pristupna pro read (tj daji se provadet selecty) - data jsou tam podle nastaveni archive_timeout.

[Franta]

Výborný článek, díky!

zálohovat celé virtuální servery pomocí snapshotů (což je jinak můj preferovaný způsob zálohování, kdy v případě obnovy stačí obnovit celý virtuální server ze zálohy a jednoduše jej spustit ve stavu poslední zálohy)

Ale stejně je dobré PostgreSQL říct, že se bude dělat snapshot, ne? Stejně tak by o tom měl vědět souborový systém, LVM...

[Heron]

Výborný článek, díky!

Díky.

Ale stejně je dobré PostgreSQL říct, že se bude dělat snapshot, ne? Stejně tak by o tom měl vědět souborový systém, LVM...

To už je mimo nad rámec článku. Jasně, když to jde, tak je to lepší. VMWare (který používáme) umí pomocí toolsů kontaktovat OS a připravit na to systém souborů (minimálně tedy udělat flush a sync FS). V případě snapshotů BTRFS (stejně asi i u ZFS) si to ten FS pořeší rovnou sám a snapshot bude udělán mezi dvěma fdatasync walu. (I když PostgreSQL na BRTFS je dost pomalý, tam to asi nikdo vážně provozovat nebude.) Druhá část odpovědi je, že ta DB musí tak jako tak umět přežít i nekorektní ukončení OS a také přežije. Je to jeden z požadavků ACID a co jsem viděl testy, tak žádná ACID DB s tím neměla problém (testovalo se vypnutí celého serveru). Potom byla data v pořádku ve stavu posledního úspěšného commitu.

[Program]

Víte, k čemu slouží ono pg_stop_backup()? Poradím, minimálně udělá checkpoint. Další nekonzistence se přepíše přehráváním wal logů, protože ty obsahují data celé stránky (min. při provádění zálohy, pokud je to v configu vyplé) a všechny stránky na kterých se co hnulo.

[Program]

Jo, i když jsem úplně nepochopil příspěvek, sorry.

[TomasVondra]

No, to pg_stop_backup zcela určitě nedělá. Předpokládám že si to pletete s pg_start_backup, který právě udělá checkpoint a zamezí změnám které by znemožnily vytvoření konzistentní kopie na úrovni filesystému.

[BrainLess]

U opravdu bussines reseni se pouzivaji draha diskova pole (EMC atd.) + drahy software ktery umi za pomoci features diskovych poli udelat konzistentni zalohu. PGSQL jsem nikdy nepouzil ale jsem rad ze se priblizuje komercnim resenim ( Oracle ). K tem zaloham to v praxi funguje tak ze se DB uvede do stavu zalohy (analogie k tomu pg_start_backup). V principu to funguje stejne zapisuje se do archive logu ( obdoba WAL logu u Oracle ) a zmeny si sice propisuji i do DB files ale nemeni se SCN v hlavicce DB souboru. Pak se pomoci HW diskoveho pole udela "snapshot" v radu jednotek sekund a DB se znovu uvede do end backup state. Takze vlastni zaloha probehne u nekolika TB databaze v radu desitek sekund, to ze to potom na pozadi diskove pole resi jeste nekolik hodin nikoho netrapi od toho tam je a je to tak spravne. Nasledne kdyz je snapshot ok, se provede odzalohovani na pasky ( nejsou pasky jako pasky viz StorageTek PowderHorn, pozdeji Sun PowderHorn a nyni Oracle PowderHorn nebo jak se to dnes jmenuje ) ... Pro zajimavost si najdete jak ten powderhorn vypada, co si tak matne pamatuji tak v max konfiguraci to bylo schopno zazalohova tusim 1200TB/hodina + celkova kapacita zalohy 28000PB. Ahoj. Linuxu zdar.

[Käyttäjä 11133]

PowerHorn je obsolete, byl nahrazený modulární knihovnou SL8500. Maximální rychlost 552.9TB/hr (nekomprimovaných) s T10000C mechanikama. V letech 2010/2011 jsme právě odstraňovali PowerHorny a nahrazovali je SL8500. SL8500 je mi mnohem sympatičtější :)

[BrainLess]

Jasne ze to tak bude, jelikoz se sotrage systemama nezivim tak to moc nesleduju. Jenom si udrzuji vseobecny prehled jak se co dneska dela ..