db.dobo.sk

Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 03. Backup DB.

2 komentárov

V postgrese existuju dva zakladne sposoby zalohy databaze:

logical backup  – v zasade vydumpovanie obsahu databazy do textovych suborov. Vytvorenie INSERTov v suboroch. Dobre pre male databazy na desktope, negaranuje navrat k presne stanovenemu PITR. Utility pg_dump a pg_restore, pomerne jednoduchy postup. Nebudem sa tomu viac venovat.

physical backup – zaloha binarnych datovych files clusteru (tzv. base backup) a naslednych WAL logov. Idealne pre velke produkcne databaze s poziadavkom na konzistenciu dat a presnu definiciu PITR.

vlastne 3 – specialnym sposobom backupu je zalohovanie pomocou replikacie

horeuvedene moznosti su nativne pre standardnu instalaciu postgresu, inak existuju samozrejme riesenia tretich stran (opensource) – napr. pgBackRest, Barman etc… Ich vyhodou je, ze backup sa da posunut na standardnu uroven kontinualneho bekapovania, volba Full/Incremental/Differential etc…

 Physical backup, alebo base backup

Zakladna myslienka je snapshot db clusteru a priebezne archivovanie WAL logov – t.j. potom je mozne lubovolne si zvolit PITR (Point In Time Recovery, alebo recovery target). Velkymi vyhodmami basebackupu je, ze a) nerobi locky na tabulkach a b) je pomerne rychly v porovnani s inymi backupami. Nevyhodou je, ze backupuje cely cluster a neda sa robit backup len parcialnych objektov (len jedna DB alebo nejaky objekt v DB).

Zakladnou utilitou je pg_basebackup, ktora je len wrapper pre binarky pg_start_backup a pg_stop_backup.

Priebeh backupu – spusti sa pg_start_backup, ktory urobi cekpoint databazy (tzv. REDO POINT) a vytvori backup_label file (subor, kde je okrem inych veci zaznamenany CHECKPOINT LOCATION – LSN cislo, kedy bol urobeny ceckpoint). Na konci sa spusti pg_stop_backup, ktory zmaze backup_label a vytvori backup_history file. Inak .backup file sa vytvara v adresari, kde sedia WAL logy…

Priebeh restoru – pri restore sa z checkpointu (REDO POINT) obnovi cluster a prehraju sa archivovane WAL logy do pozadovaneho bodu.

postgres_restore

Restore procesne:

  1. Poziadavok na restore, zastavime posgresql stroj
  2. Odstranime vsetky subory v datarootu
  3. Nakopirujeme subory zo zalohy basebackupu do datarootu (pozor na opravnenia, vsetko ako postgres, bacha na symlinky pre pg_tblspc/)
  4. Vytvorime si recovery.conf (vid nizsie), kam zadame hlavne cestu k archivovanym logom a pripadne dalsie parametry
  5. Nastartujeme DB server, ten podla recovery conf urobi restore

Ako prebieha restore: Postgres sa znova nastartuje a pokial ma v strukture subor backup_label a je tam pritomny konfigurak recovery.conf, tak sa prepne do PITR modu a bude rekoverovat cluster podla parametrov v konfiguraku, typicky priklad:

restore_command = 'cp /mnt/server/archivedlogs/%f %p' - lokalizacia archivovanych WAL logov
recovery_target_time = '2018-09-24 05:012 GMT' - cas, do ktoreho chceme restorovat, pokial 
nie je uvedeny, tak recovery pouzije vsetky WAL logy a restorne to tam, kam az to pojde

 

Inak pr enapisanie recovery.conf je idealny vzorovy sample subor v /usr/share/postgresql/../recovery.conf.sample

Na konci restoru sa: a) zmaze recovery.conf a vytvori recovery.done  (teda, on ho vlastne len premenuje, takze mas konf z posledneho restoru) a b) zapise subor timeline historie – 00000002.history – jeho inkrementalny nazov je tzv. timelineId – ukazatel na verziu clustru (po restore sa uz nejedna o povodny cluster, ale jeho kopiu.). Ma to pekne konzekvencie pre WAL logy – prvych 8 cifier nazvu WAL logu je totiz tento timelineId, tudiz logy generovane po restore databazy budu napr. 00000002000000000000000F. Obsahom suboru timeline.history je zkratkovit acharakteristika toho, odkial sa zacinalo (cas a LSN).

postgres_timelineId

Basebackup cez API

Basebackup sa da spustat priamo v postgrese cez jeho API – SELECT pg_start_backup(‘label’, false, false); Vid doku.

Zaver

  • Princip basebackupu je jednoduchy – urobi sa checkpoint kopia clustru a potom sa uz odlievaju len WAL logy. Pri restore sa obnovi kopia klastru a doluje sa logy do pozadovaneho bodu. Z toho vyplyva:
  • bud si isty, ze logy archivujes a vies kam. Idealne na bezpecne miesto mimo DB server
  • archivaciou logov NEZALOHUJES datafily a konfiguraky postgresu, len zmenovost databazovych dat
  • archivacia WAL logov prebieha len na zaplnenych logoch, takze keep in mind, ze restore zalozeny na archivovanych logoch bude postradat info z posledneho (zapisujuceho) logu. Ukoncenie zapisu a odarchivovanie sa da vynutit cez pg_switch_wal
  • System timelinov vyplyva z nasledovneho scenara – pokial dropnem tabulku v utorok a pridem na to vo stvrtok, tak neni problem sa restorom vratit do utorka. Ale po case zistim, ze som to vlastne chcel restornut na stredu a mam problem, pretoze WAL logy sa uz medzitym prepisali. Preto je lepsie drzat oddelene vyvojove linie WAL logov s ciselnym prefixom, ktory ukazuje na separatne linie existencie databazy.

 

píše: ďobo

Júl 17th, 2018 o 7:03 am

chlievik: postgresql

2 odpovedí to 'Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 03. Backup DB.'

Subscribe to comments with RSS or TrackBack to 'Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 03. Backup DB.'.

  1. From the PostgreSQL version 12 onwards there is no recovery.conv file to perform recovery from basebackup
    https://fluca1978.github.io/2019/07/08/PostgreSQL12Recovery.html

    fluca

    5 Nov 19 at 10:03

  2. skvely komand, ked potrebujes urobit basebackup a pouzit ju pre restore ucely na inom stroji, ale nemas miesto na to, aby si to zabalil do taru a preniesol az potom.
    Spusti to basebackup, zapakuje do taru, prepajpuje sshckom na druhy srtoj a tam rovno rozbaluje (nutne mat nazdielane ssh kluce):

    pg_basebackup -D – -F t -P -R -X none | ssh DRUHY_SERVER ‘cd /var/lib/pgsql/11/data ; tar xf -’

    ďobo

    13 Dec 19 at 15:21

okomentuj