db.dobo.sk

Wal logy su REDO logy, alebo inak boli nazyvane aj Xlogy, a su to vlastne transakcne logy :). Takze teraz poporiadku – co su v Oracle REDO logy, su v Postgrese WAL logy. Do verzie 10 v tom bol naming chaos, nakolko sa nazyvali Xlogy.

Princip

Princip WAL logov je zalozeny na myslienke, ze ked databaza zbuchne, tak transakcie, ktore nie su zapisane do datafilov (su zatial v shared buffer pool), su zachranene, lebo su zapisane do redo logov a preto sa po zbuchnuti daju obnovit. Podobne, ak pride k chybe pri zapise do datafilov a tie su corrupted, tak sa da vratit k poslednemu checkpointu a doart to WAL logmi. WAL znamena Write Ahead Log. Otazka – no a aky je rozdiel medzi zapisom do datafilov a do wal logov? V podstate ziadny, okrem rychlosti. Takze wal logy garantuju urcitu bezpecnost dat bez znizenia performance.

Struktura WAL logu

Najdolezitejsi part wal logu je tzv. XLOG record – de facto zmenovy datovy udaj, sparovany s LSN. Wal logy obsahuju aj udaj o checkpointe (kedy a kde), t.j. kedy bol naposledy zapisany do datovych fajlov REDO point.

Wal logy su 16 MB subory, ich nazov sa vytvara pomocou tejto kuzelnej formulky:

WAL segment file name=timelineId+(uint32)LSN/116M∗256+(uint32)(LSN/116M)%256

Procesy

Wal writer – zapisovac XLOG zaznamov do wal logov. Defaultne kazdych 200 milisekund a neda sa disablovat (len zmenit interval v konfiguraku)

Checkpoint proces zapisuje checkpointy z wal logov a to defaultne kazdych x sekund (premenna checkpoint_timeout), alebo ked stupne velkost wal logov nad x GB  (premenna max_wal_size). Okrem toho, ze zapise REDO point do storage, zapise ho aj do pg_control filu, ktory je klucovy v pripade restoru. Pozor, pg_control je binarny subor, cita sa utilitou pg_controldata

checkpoint

Checkpoint je zapis dat do datafilov. V zasade sa rozliduje medzi timed (podla checkpoint_timeout) a requested (ked sa zavola komand CHECKPOINT, alebo za zaplni wal log). Viac o checkpointe.

WAL switching a archivacia

WAL logy sa switchuju (nieco ako logrotate), a to ked sa a) zaplni, b) ked sa zavola funkcia pg_switch_xlog, alebo c) alebo sa vyvola archivacia wal logu. Vzhladom na to, aku dolezitu ulohu maju WAL logy (je to zurnal vsetkych dat), tak je zahodno ich priebezne niekam archivovat a v pripad epotreby (restore) opat nahrat do DB a tym sa dostat k ziadanemu bodu stavu DB. Odlievaniu logov sa odborne hovori wal archiving, ale v principe je to vlastne inkrement8lny backup :) (to aby clovek nebol za jelito). V pripade real-timoveho odlievania logov je to replikacia.

V okamihu, ked dojde ku switchu wal logu, alebo je evokovany komand archivovania, dojde k odlietiu wal logu na miesto zalohy. Je to konfigovane v hlavnom konfiguraku postgresql.conf a pouzivaju sa na to normalne unixove utility (e.g. archive_command = ‘cp %p /home/postgres/wal_archives/%f‘). Dobrou praxou je archivovat na nejaky bezpecny nfs share a tak.

Priklady:

# Copy the file to a safe location (like a mounted NFS volume)
archive_command = ‘cp %p /mnt/nfs/%f’

# Not overwriting files is a good practice
archive_command = ‘test ! -f /mnt/nfs/%f && cp %p /mnt/nfs/%f’

# Copy to S3 bucket
archive_command = ‘s3cmd put %p s3://BUCKET/path/%f’

# Copy to Google Cloud bucket
archive_command = ‘gsutil cp %p gs://BUCKET/path/%f’

# An external script
archive_command = ‘/opt/scripts/archive_wal %p’

Ine dolezite parametre wal archivovania (v postgresql.conf):

• v pripade externeho skriptu pouziteho pre archiving je dolezite, aby ho mohol spustit user postgres
• wal log bude oznaceny ku zmazaniu, ak bol sprocesovany (odarchivovany) skriptom. Nie je tam nijaka pokrocila logika – skript musi vratit 0 a pokial nie, tak je znova  aznova spustany s nadejou, ze dobehne s 0
• do skriput je velmi uzitocne zapracovat podmienku proti prepisu wal logov s rovnakym menom

wal_level = oznacuje typ struktury wal logu (minimal, replica, or logical). Minimal poskytuje len zakladne datove udaje a staci pre obnovenie z crashu databaze, ale neumoznuje archiving (pokial je archive_mode = on, tak wal_level musi byt aspon replica). Logical level je vyzadovany pre replica streaming (real time replikovanie databazi).

min_wal_size a max_wal_size – tymto obmedzenim je mozne udrziavat wal logy v rozumnej velkosti a vynucovat ich switchovanie v rozumnom case