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í
×

dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 206 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

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

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

    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ář

    Marek Stopka avatar 24.10.2012 00:58 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    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: 51 | 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: 51 | 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.
    Marek Stopka avatar 24.10.2012 13:49 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    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: 51 | 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: 15
    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).
    Marek Stopka avatar 24.10.2012 01:00 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    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: 51 | 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: 15
    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.
    Marek Stopka avatar 26.10.2012 13:10 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    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.