db.dobo.sk

Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 04. Wal logy.

bez komentára

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 dohrat 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

postgres_wal

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 spinavych pamatovych bufferov (shared buffers) do datafilov. Je to metoda, jak urobit data persistent (napr. pri vypadku prudu; aj ked to nie je uplne pravda, pretoze data su uz zapisane vo WAL logoch) a hlavne urobit bod, z ktoreho sa bude pripadne databaza recoverovat. Z zasade existuju 2 druhy checkpointov:

  • timed checkpoint = zapisuje sa pravidelne v intervale definovanom v postgresql.conf
  • requested checkpoint = zapisuje, pokial sa naplni (a switchne) WAL log, alebo pokial sa checkpoint vynuti prikazom CHECKPOINT; requested checkpointov by malo byt radovo mensi pocet, nez timed

Ako prebieha zapis checkpointu:

  • robi ho proces checkpointer, ktory bude zapisovat len tie buffery, ktore su oznacene ako zmenene
  • samotny checkpoint je rozlozeny v case (checkpoint_completion_target) a postupne zapisuje.
  • start checkpointu je zapisany do WAL logu a do kontrolneho suboru (/global/pg_control) – bude tvorit bod, od ktoreho sa bude obnovovat po pripadnom pade
  • start aj dokoncenie checkpointu moze byt logovane (log_checkpoints = on)

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 pripade potreby (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 inkrementalny 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

píše: ďobo

August 5th, 2018 o 11:21 am

chlievik: postgresql

okomentuj