Jak PostgreSQL przechowuje dane: struktura bazy i dziennik transakcji (WAL)

Kiedy pracujesz z bazą danych, wszystko wydaje się całkiem proste: dodałeś wiersz, zaktualizowałeś rekord, usunąłeś klienta. Ale za tą prostotą kryje się skomplikowany i przemyślany mechanizm. Gdzie tak naprawdę są przechowywane te dane? Jak PostgreSQL potrafi niczego nie zgubić, nawet jeśli serwer nagle padnie?

Żeby to ogarnąć, trzeba zrozumieć dwie kluczowe rzeczy: gdzie fizycznie leżą dane (tabele, indeksy, info systemowe) i jak działa mechanizm ochrony tych danych — dziennik transakcji, czyli WAL (Write-Ahead Logging).

Cała baza danych PostgreSQL jest przechowywana jako zestaw plików w specjalnym katalogu — data_directory. Zazwyczaj znajdziesz go tutaj:

/var/lib/postgresql/17/main

W tym folderze jest całe serce bazy: same tabele, indeksy, metadane i ustawienia. Tam też znajduje się dziennik WAL — mechanizm, który jako pierwszy przyjmuje wszystkie zmiany. Zanim dane trafią do tabeli na dysku, są zapisywane do WAL. To taki brudnopis, w którym baza notuje każdy krok, żeby w razie awarii dało się wszystko odtworzyć do ostatniej operacji.

Dzięki temu podejściu PostgreSQL zapewnia niezawodność i odporność, nawet w najbardziej niestabilnych warunkach.

Tabele

Każda tabela to fizycznie osobny plik albo zestaw plików. Te pliki są w podkatalogu base/. Struktura wygląda mniej więcej tak:

$PGDATA/base/
├── 16384/
│   ├── 12345   ← tabela
│   ├── 12346   ← indeks
│   └── ...

• 16384 — to wewnętrzny identyfikator bazy danych (OID).
• 12345 — identyfikator konkretnej tabeli.

Jeśli tabela jest duża, PostgreSQL dzieli ją na segmenty po 1 GB:

12345
12345.1
12345.2
...

Pliki nie zawierają "wierszy" jak w tekstowym CSV — to format "binarnych stron" po 8 KB.

WAL: Write-Ahead Logging — to nie jest zwykły "log"

Teraz przejdźmy do jednej z najważniejszych i często źle rozumianych części PostgreSQL — WAL, czyli Write-Ahead Logging. Mimo słowa log w nazwie, WAL to nie zwykły plik tekstowy logów, jak logi błędów czy zapytań. To kluczowy mechanizm spójności i odzyskiwania danych, działający na poziomie niskopoziomowych zmian w systemie plików.

WAL to nie raport zdarzeń, tylko wstępny zapis wszystkich zmian, które PostgreSQL zamierza zrobić z danymi. Ten zapis następuje przed faktyczną modyfikacją tabel na dysku. Dlatego właśnie nazywa się write-ahead — "zapisz najpierw".

Kiedy np. wstawiasz nowy wiersz do tabeli, PostgreSQL:

1. NIE aktualizuje od razu tabeli na dysku — to byłoby wolne i niebezpieczne.
2. Najpierw zapisuje do WAL, że ten wiersz będzie dodany.
3. Dopiero potem, kiedy jest wygodnie (np. w tle), dane faktycznie trafiają do tabeli.

To działa jak czek w banku: najpierw go podpisujesz (WAL), a dopiero potem bank aktualizuje konto (tabela). Jeśli coś pójdzie nie tak — czek nadal masz i możesz powtórzyć operację.

Format i struktura WAL

• Pliki WAL są przechowywane w formacie binarnym.
• Każdy plik to ściśle uporządkowany strumień operacji, które opisują wewnętrzne zmiany stron danych, struktur indeksów, commitów itd.
• Jeden plik WAL ma stały rozmiar — domyślnie 16 MB.

Ważne: WAL nie zawiera "komend SQL" ani "wierszy tabeli" w znanej formie. Zawiera instrukcje dla silnika PostgreSQL, jak odtworzyć zmiany, strona po stronie.

Co się stanie przy awarii?

Jeśli serwer PostgreSQL nagle padnie — powiedzmy, przez nagły brak prądu — nie wszystko stracone. Przy następnym uruchomieniu baza nie panikuje, tylko spokojnie ładuje z dysku ostatnią zapisaną „stabilną” wersję danych. Potem bierze dziennik transakcji (WAL), w którym są wszystkie ostatnie zmiany, i spokojnie je „dokręca” — stosuje to, co jeszcze nie trafiło do głównych plików. W efekcie baza wraca do w pełni spójnego stanu, jakby nic się nie stało.

Dodatkowe możliwości WAL

Point-In-Time Recovery (PITR). Przechowywanie plików WAL pozwala odtworzyć bazę do dowolnego momentu między dwoma pełnymi backupami.

Replikacja strumieniowa. PostgreSQL może przesyłać wpisy WAL na inny serwer w czasie rzeczywistym. To pozwala mieć hot standby — kopię bazy zsynchronizowaną z główną.

Odzyskiwanie przyrostowe. W połączeniu z pełnym backupem, WAL pozwala odtworzyć tylko zmiany, bez kopiowania całej bazy od nowa.

Tworzenie backupów binarnych: pg_basebackup

Jeśli już trochę ogarniasz pg_dump, to wiesz, że świetnie nadaje się do tworzenia backupów logicznych (czyli kopiowania struktury bazy i jej danych jako zapytań SQL). Ale co, jeśli musisz zrobić backup fizyczny? Na przykład pełną kopię lustrzaną wszystkich plików bazy? Tu z pomocą przychodzi narzędzie pg_basebackup.

pg_basebackup — to narzędzie pozwalające tworzyć fizyczne kopie danych PostgreSQL. Jest szczególnie przydatne przy dużych bazach, gdzie trzeba efektywnie zarządzać procesem odzyskiwania. Największy plus pg_basebackup to to, że robi to bardzo szybko.

Podstawowa składnia komendy pg_basebackup

Praca z pg_basebackup zaczyna się od zrozumienia jego komendy. Wykonujesz ją w terminalu i wygląda tak:

pg_basebackup -D /backup_directory -F tar -z -P

Rozłóżmy to na czynniki:

• -D /backup_directory — wskazuje katalog, gdzie będą zapisane twoje pliki backupu.
• -F tar — format danych. Opcja tar tworzy plik archiwum w formacie .tar. Możesz też użyć plain, żeby mieć strukturę plików bazy.
• -z — kompresuje backup, co pozwala zaoszczędzić miejsce na dysku. Zawsze spoko, jak backup zajmuje mniej miejsca!
• -P — pokazuje postęp w czasie rzeczywistym. To taki bonus: widzisz, że proces idzie i serwer nie „zawisł”.

Przykład użycia:

pg_basebackup -D /backups/university_backup -F tar -z -P

Po wykonaniu komendy w katalogu /backups/university_backup pojawi się backup w formacie .tar.

Zalety korzystania z pg_basebackup

Wydajność: backupy przyrostowe pozwalają nie kopiować niezmienionych danych, co oszczędza czas i miejsce.

Prostota użycia: narzędzie pg_basebackup automatycznie ogarnia wszystkie szczegóły, w tym pliki WAL.

Niezawodność: dzięki integracji z mechaniką PostgreSQL, pg_basebackup tworzy dokładne kopie całej bazy, które łatwo odtworzyć.

Przykłady użycia

No to do praktyki. Poniżej masz realne przykłady, jak użyć pg_basebackup do robienia backupów bazy PostgreSQL. Pokażemy, jak zrobić podstawowy backup, jak dodać kompresję i jak włączyć archiwizację dziennika transakcji (WAL), żeby móc odtworzyć „do punktu w czasie”. Te komendy nadają się zarówno na start, jak i do bardziej zaawansowanych scenariuszy.

Tworzenie podstawowego backupu

pg_basebackup -D /backups/full_backup -F tar -z -P

Efekt: pełny backup bazy w archiwum .tar.

Ustawianie kompresji i formatu

Zróbmy backup danych z wysokim poziomem kompresji:

pg_basebackup -D /backups/full_backup -F tar -z -Z 9 -P

Tutaj -Z 9 ustawia poziom kompresji (max to 9).

Archiwizacja WAL

Jeśli ustawisz archiwizację WAL, baza może być odtworzona do dowolnego momentu. Komenda do ustawienia backupu WAL:

pg_basebackup -D /backups/incremental_backup -F tar -z -P --wal-method=archive