abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
13.9. 22:00 | Nová verze

Po roce a čtvrt od vydání verze 12.0 byla vydána verze 13.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání. Zmínit lze například podporu Dolby TrueHD a DTS-HD Master Audia.

Ladislav Hagara | Komentářů: 2
13.9. 16:33 | Zajímavý projekt

Blockchainový projekt Tezos nedávno prošel procesem hard-forku a zrodil se nový projekt Dune Network. Držitelé XTZ tokenů si již bezpečně mohou vyzvednout své DUN tokeny a delegovat je na nějakou z veřejných Dune baker služeb jako je třeba Dune Whale.

Mark Stopka | Komentářů: 4
12.9. 23:33 | Komunita

Na Humble Bundle lze zdarma na Steamu získat Endless Space Collection, tj. počítačové hry Endless Space a Endless Space - Disharmony. Endless Space Collection je oficiálně pro Windows a macOS. Díky Protonu ale také pro Linux. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 3
12.9. 20:44 | Bezpečnostní upozornění

Společnost AdaptiveMobile Security zveřejnila informace o možných útocích na SIM kartu. Útočník může pomocí SMS řídit SIM kartu a skrze ní mobilní telefon oběti. Více na stránce Simjacker.

Ladislav Hagara | Komentářů: 15
12.9. 19:44 | Nová verze

Po půl roce vývoje od vydání verze 3.32 bylo vydáno GNOME ve verzi 3.34 s kódovým názvem Thessaloniki. Videoukázka na YouTube. Vydání obsahuje 23 929 změn od přibližně 777 přispěvatelů. Přehled novinek i s náhledy v již přeložených poznámkách k vydání a v novinkách pro vývojáře a správce systémů.

Ladislav Hagara | Komentářů: 13
12.9. 11:22 | Pozvánky

Největší česká linuxácká akce LinuxDays 2019 má hotový program. Těšit se můžete na přednášky, workshopy, stánky a spoustu doprovodného programu. Zároveň s programem byla také spuštěna registrace účastníků, takže se můžete přihlašovat. Vstup je jako obvykle zdarma. Konference LinuxDays se uskuteční 5. a 6. října v pražských Dejvicích na FIT ČVUT.

Petr Krčmář | Komentářů: 7
11.9. 23:14 | Pozvánky

Spolu se společnou celosvětovou stávkou za klima proběhne 20. září také digitální stávka za klima, které se může snadno zúčastnit každý web. Česká odnož iniciativy podporuje akci Týden pro klima, v jejímž rámci probíhá mnoho aktivit po celé ČR. Zájemci o účast najdou dokumentaci a technickou podporu na českém webu akce.

milosk | Komentářů: 374
11.9. 22:11 | Komunita

Richard Hughes na svém blogu informuje, že se společnost Acer zapojila do projektu LVFS (Linux Vendor Firmware Service). Uživatelé zařízení od Aceru tak budou moci provádět aktualizace firmwarů přímo z Linuxu. Prvním podporovaným zařízením je notebookem Aspire A315. Přehled všech podporovaných zařízení na stránkách LVFS.

Ladislav Hagara | Komentářů: 0
11.9. 21:11 | Nová verze

Google Chrome 77 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 77.0.3865.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 52 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
11.9. 14:11 | Nová verze

Po pěti měsících od vydání verze 5.6 byla vydána verze 5.7 svobodného multiplatformního softwaru pro konverzi a zpracování digitálních fotografií primárně ve formátů RAW RawTherapee (Wikipedie). Nová verze RawTherapee je k dispozici také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

Ladislav Hagara | Komentářů: 0
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (23%)
 (3%)
 (12%)
 (30%)
 (31%)
 (2%)
Celkem 117 hlasů
 Komentářů: 15, poslední dnes 16:45
Rozcestník

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

24. 10. 2012 | Tomáš Crhonek | Návody | 4236×

Pro zálohování databázového serveru se obvykle používají nástroje pg_dump v kombinaci s jeho obnovením pomocí standardního klienta psql (to v případě logické zálohy, která probíhá vytvořením sekvence SQL příkazů) nebo nástroje pg_restore. Tato klasická metoda zálohování pomocí kompletních dumpů databáze má své přednosti ale i omezení. Mezi přednosti patří jistě to, že je možné zálohovat kteroukoliv databázi, případně jen několik tabulek.

V případě logických dumpů (sekvence SQL příkazů) dokonce i množnost zasahovat do zálohovaných dat (a efektivně tak použít tuto metodu i na hromadnou změnu dat). Hlavní a podstatná nevýhoda zálohování pomocí dumpů je omezení velikosti. Pomocí dumpů je vhodné zálohovat pouze malé databáze o velikosti několika desítek gigabajtů. Pro větší databáze bude čas zálohy a zejména obnovy velmi dlouhý a databázový server bude na dlouhou dobu velmi zatížen.

Zálohování metodou pitr je naproti tomu velice rychlé a kontinuální (využívá stávajícího mechanismu zápisu změn v databázi nejprve do WAL logů a až poté do datových souborů). Obnova je v porovnáním s obnovou logických dumpů velmi rychlá. Lze tak velice rychle obnovit kompletní databázový server bez ohledu na jeho velikost. Tímto způsobem ovšem není možné zálohovat pouze vybrané databáze, ani zasahovat do obnovovaných dat, zálohuje se vždy celý databázový server.

Obsah

Write Ahead Log (WAL)

link

Transakční databáze zapisují všechny změny dat nejprve do transakčního logu a až poté do datových souborů. S WAL logy se pracuje výhradně sekvenčně a jejich ukládání a následné čtení je velmi rychlé. Po nějakém čase, až se transakční logy (u Postgresu je to série souborů po 16 MiB, jejiž počet je nastaven v konfiguraci) naplní, dojde k události checkpoint (kterou lze vyvolat i příkazem CHECKPOINT;) a data se zapracují do trvalých datových souborů. Na tuto nákladnou operaci však klient nemusí čekat (data z jeho potvrzené transakce jsou již bezpečně na disku právě ve WAL). Při pádu databázového serveru (například výpadek napájení) se po jeho opětovném spuštění sekvenčně projde celý WAL a nezapsané změny se zapíší do datových souborů. Tím je zajištěna rychlost a také bezpečí dat, klient čeká pouze na rychlý sekvenční zápis a fsync WAL logu, který je později zapracován do datových souborů.

Vzhledem k tomu, že v těchto souborech jsou všechny změny a že se s nimi pracuje výhradně sekvenčně (jednou naplněný soubor logu se už nemění), je možné tento soubor odkopírovat na jiné úložiště a později jej využít při obnovení serveru po jeho totálním pádu.

A na tom je právě založena metoda zálohy WAL logů a obnovení metodou PIRT. WAL logy se za běhu databáze kopírují na jiné úložiště a jednou za čas se provede plná záloha prostým odkopírováním adresáře s databází. Obnova potom spočívá v obnovení plné zálohy a v přehrání všech uložených WAL logů.

Nastavení migrace WAL logů na vzdálený adresář

link

Nejprve je třeba nastavit migraci WAL logů na externí úložiště. Na tomto místě bychom čekali nastavení adresáře, kam se mají logy migrovat, ovšem PostgreSQL dává administrátorovi do ruky daleko mocnější nástroj. Nastavuje se příkaz (skript, chcete-li), který požadovanou akci udělá. Je pouze na administrátorovi jakou metodu si zvolí (od jednoduchého cp, až třeba po speciální zálohovací nástroj).

K tomu slouží parametr archive_command a v nejjednodušší funkční podobě může vypadat takto:

archive_command = 'test ! -f /storage/WAL/%f && cp %p /storage/WAL/%f'

Kde %f je zástupný znak pro jméno souboru logu a %p je celá cesta k souboru (nejčastěji /var/lib/pgsql/data/pg_xlog/jmeno_souboru), odkud se má soubor zkopírovat. Soubory se budou kopírovat do vzdáleného NFS adresáře připojeného do /storage/WAL. Na skript jsou kladeny požadavky, nesmí se přepisovat soubor stejného jména na vzdáleném úložišti a při jakékoliv chybě musí vrátit nenulový návratový kód. Naopak nula se musí vrátit pouze v případě úspěchu a bezpečného uložení souboru na externí úložiště. Výše zmíněný skript z dokumentace tyto požadavky splňuje.

Dále je v postgresql.conf potřeba nastavit úroveň WAL logů (v základním nastavení je to minimal, která je vhodná pro bezpečné obnovení databáze po pádu, ale nelze ji používat pro tuto metodu zálohování) a také aktivovat archivaci:

wal_level = archive
archive_mode = on

To je z nastavení migrace wal logu vše a po restartu služby PostgreSQL by se měly na vzdáleném úložišti ukládat 16 MiB soubory logu. Toto je třeba bezpečně ověřit ještě před zahájením samotné zálohy a není od věci si také vyzkoušet rychlost přenosu logů při zatížení db například vytvořením obrovské tabulky (třeba pomocí pgbench -i -s 1000).

Zahájení plné (base) zálohy

link

Když už se WAL logy spolehlivě migrují na externí úložiště, je možné provést samotnou plnou zálohu. Ta spočívá v prostém odkopírování adresáře (nejčastěji /var/lib/pgsql/, jiné distribuce to mohou mít na jiných místech) na externí úložiště (ideálně někam k WAL logům). Před kopírováním je třeba uvést PostgreSQL do stavu vhodném pro kopírování datových souborů.

K tomu slouží SQL příkaz SELECT pg_start_backup('label');, který je třeba spustit jako superuživatel postgres, nebo jiný vyhrazený uživatel s právy superuser.

Parametr label je pro označení zálohy a slouží jen jako poznámka bez technického významu. Před kopírováním adresáře s databází je nutno počkat až tento příkaz doběhne, což může trvat delší čas. Doba plné base zálohy, tedy doba mezi příkazy pg_start_backup() a pg_stop_backup(), není kritická a databáze funguje pro klienty zcela bez komplikací.

Plná base záloha

link

Plná záloha adresáře s databází (/var/lib/pgsql/). Opět je možné použít jakýkoliv nástroj pro spolehlivé zkopírování celého adresáře (cp, tar, rsync apod.).

cp -a /var/lib/pgsql/ /storage/WAL/base_backup

Není třeba zálohovat podadresář pg_xlog (což je adresář, ve kterém má PostgreSQL WAL logy, které jsou ale už v tuto chvíli odkopírované i na externí úložiště) případně je nutno před obnovením zálohy jeho obsah vymazat (viz obnovení zálohy).

Ukončení base zálohy

link

Po odkopírování adresáře s databází je nutné base zálohu ukončit, opět jako superuživatel:

SELECT pg_stop_backup();

Tímto postupem je plná záloha hotová a WAL logy se migrují pryč na externí úložiště. Zálohování tedy probíhá systémem plná záloha (base backup) a potom se migrují jen změny pomocí ukládání wal logů na externí úložiště. Nemá smysl ukládat WAL logy starší, než je base záloha (wal logy vytvořené před zahájením plné zálohy je tak možno smazat).

Obnova

link

Nejprve je nutno obnovit adresář (/var/lib/pgsql/) z poslední plné zálohy:

cp -a /storage/WAL/base_backup /var/lib/pgsql/

Pokud se zálohoval i adresář pg_xlog, je třeba vymazat jeho obsah (rm pg_xlog/* v příslušném adresáři databáze). Pokud se nezálohoval, je třeba jej před spuštěním serveru vytvořit s patřičnými právy a vlastníkem (mkdir pg_xlog && chown postgres.postgres pg_xlog). Osobně doporučuji dělat věci co možná nejjednodušeji a zálohu dělat jako kopírování celého adresáře psql včetně pg_xlog (jehož velikost je i pro doporučených 30 segmentů malá, asi 1,5 GiB oproti celé databázi, která může mít stovky GiB) a potom jej před obnovou jednoduše promazat, než si komplikovat zálohu exclude pravidly a při obnově vytvářením adresáře s právy. Při obnově je člověk většinou ve stresu (obnovuje se po havárii) a čím méně kroků obnovy, tím lépe.

Vytvoření recovery.conf

link

Soubor recovery.conf (pozor, tento soubor musí být v adresáři databáze, tedy v adresáři, kde jsou i podadresáře base, pg_xlog apod.; některé distribuce, třeba Debian, mají ostatní konfigurační soubory v /etc/postgresql/verze/main/, ale soubor recovery.conf databáze očekává právě ve svém základním adresáři) slouží pro určení cesty (resp opět se jedná o skript) k zálohovaným WAL logům. V nejjednodušší variantě:

restore_command = 'cp /storage/WAL/%f %p'

Spustit službu PostgreSQL

link

V jeho logu lze sledovat průběh obnovy WAL logů, například:

2012-09-11 12:46:22 CEST LOG:  restored log file „00000001000000000000003D“ from archive

Po dokončení obnovy je v logu hláška:

2012-09-11 12:46:46 CEST LOG:  database system is ready to accept connections

A soubor recovery.conf je automaticky přejmenován na recovery.done. Tento soubor lze v adresáři nechat, bude součástí další base zálohy. V případě další obnovy jej stačí přejmenovat zpět na recovery.conf. Opět se jedná o ulehčení kroků obnovy.

Po dokončení obnovy se lze připojit k db, která je ve stavu posledního WAL logu. Databázový server lze obnovit i k libovolnému bodu v čase, případně k přesnému číslu transakce (pokud například víme, že v transakci x došlo k zavolání příkazu DROP, je možné server obnovit ke stavu transkakce x-1). Více si lze přečíst k dokumentaci k souboru recovery.conf.

Závěr

link

K tomuto způsobu zálohování a obnovy jsme přikročili u jednoho významného projektu a to ze dvou hlavních důvodů. Zákazník z technických důvodů nechce a nemůže 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). Druhým důvodem je očekávaná velikost databáze ve stovkách gigabajtů dat a je tedy nemožné zálohovat a především obnovit tyto servery se stanoveném čase pomocí klasických dumpů.

Zálohování a obnova pomocí metody pitr je naproti tomu velmi rychlá (kromě base zálohy databázový server nedělá nic navíc, kromě občasného odkopírování obyčejného souboru na NFS) a v případě obnovy se nakopíruje base zpět a přejmenuje se soubor recovery.conf. Rychlost obnovy potom probíhá rychlostí sítě, typicky 100 MiB/s. Obnova wal je z principu práce databáze velmi rychlá a spolehlivá.

V praxi je třeba rozhodnout, jak zacházet se staršími wal logy a base zálohami, stejně jako je tomu u každé zálohy. Je třeba si uvědomit, že ukládané wal logy mohou být snadno větší, než je velikost databáze na disku. Na disku je aktuální stav, zatímco wal logy obsahují úplně všechny změny a vytvoření například 32 GiB databáze zabere postupně o něco více než 32 GiB wal logů a také odpovídající místo na disku a tedy i v následující base záloze.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Mark Stopka avatar 24.10.2012 00:58 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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 avatar 24.10.2012 07:44 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
24.10.2012 09:22 Lampa
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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
24.10.2012 10:27 Pavel Francírek | skóre: 6
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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 avatar 24.10.2012 10:55 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
Mark Stopka avatar 24.10.2012 13:49 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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 avatar 24.10.2012 14:05 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.

29.10.2012 16:01 TomasVondra | skóre: 16
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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).
Mark Stopka avatar 24.10.2012 01:00 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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 :) ).
24.10.2012 06:53 Lampa
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
24.10.2012 11:50 Franta
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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 avatar 24.10.2012 12:50 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.

24.10.2012 13:48 Program
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
24.10.2012 13:49 Program
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
Jo, i když jsem úplně nepochopil příspěvek, sorry.
29.10.2012 15:52 TomasVondra | skóre: 16
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
26.10.2012 11:16 BrainLess
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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.
Mark Stopka avatar 26.10.2012 13:10 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
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ší :)
26.10.2012 14:03 BrainLess
Rozbalit Rozbalit vše Re: Zálohování a obnova PostgreSQL metodou PITR (point in time recovery)
Jasne ze to tak bude, jelikoz se sotrage systemama nezivim tak to moc nesleduju. Jenom si udrzuji vseobecny prehled jak se co dneska dela ..

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.