db.dobo.sk

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.

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).

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.