Gdzie są katalogi i pliki klastra PostgreSQL (PGDATA)

PostgreSQL

Gdzie są katalogi i pliki klastra PostgreSQL (PGDATA)

W skrócie

Prędzej czy później zejdziesz na poziom systemu plików: żeby przejrzeć logi, podmienić parametr, sprawdzić, co zjada miejsce, albo przenieść klaster. Kłopot w tym, że PostgreSQL nie ma jednej stałej ścieżki - Debian trzyma dane inaczej niż Red Hat, a instalacja ze źródeł jeszcze inaczej. Zamiast zgadywać, warto raz zrozumieć, gdzie zapytać o ścieżkę i co znaczą poszczególne podkatalogi katalogu danych, zwanego PGDATA.

Jak to wygląda w praktyce

Klasyczna sytuacja: log serwera mówi o problemie, a Ty szukasz katalogu danych, żeby przejrzeć pliki logów albo poprawić postgresql.conf. Sprawdzasz oczywiste miejsca i okazuje się, że na Ubuntu dane leżą pod /var/lib/postgresql/16/main, a pliki konfiguracyjne w zupełnie innym drzewie: /etc/postgresql/16/main. Na systemach z rodziny Red Hat wszystko jest razem w /var/lib/pgsql/16/data. Wchodzisz do katalogu danych i widzisz kilkanaście podkatalogów o skrótowych nazwach - base, global, pg_wal, pg_xact - bez pojęcia, który z nich jest bezpieczny do oglądania, a który to wnętrzności silnika, gdzie ręczna zmiana rozwala bazę.

Dlaczego tak się dzieje

Rozjazd bierze się z konwencji pakietów. Debian i Ubuntu mają narzędzia obsługujące wiele wersji i klastrów obok siebie (stąd układ wersja/nazwa i rozdzielenie danych od konfiguracji do /etc), a Red Hat trzyma domyślny klaster w jednym drzewie data. Sam PostgreSQL nie narzuca ścieżki - podaje ją przy inicjalizacji klastra i zapamiętuje jako PGDATA. Wewnątrz tego katalogu układ jest już stały i taki sam wszędzie: base zawiera właściwe dane, po jednym podkatalogu na bazę (nazwanym numerem OID), global trzyma obiekty wspólne dla całego klastra (jak lista ról), pg_wal to dziennik zapisów z wyprzedzeniem (Write-Ahead Log), pg_xact pilnuje statusów transakcji, a pliki tekstowe postgresql.conf, pg_hba.conf i postgresql.auto.conf odpowiadają za konfigurację i reguły dostępu. Plik PG_VERSION mówi, w jakiej wersji format danych został zapisany.

Jak to rozwiązać krok po kroku

1. Zapytaj sam serwer o ścieżkę - to jedyny pewny sposób niezależny od dystrybucji: SHOW data_directory; w psql albo dowolnym kliencie. Zwróci pełną ścieżkę do PGDATA.
2. Sprawdź, gdzie realnie leżą pliki konfiguracyjne (na Debianie to inny katalog niż dane): SHOW config_file;, SHOW hba_file;. Dzięki temu edytujesz właściwy plik, a nie kopię, która nic nie zmienia.
3. Jeśli nie możesz połączyć się z bazą, odczytaj ścieżkę z definicji usługi: na systemd systemctl show -p Environment postgresql@16-main pokaże ustawioną zmienną PGDATA, a proces zobaczysz w ps aux | grep postgres - główny proces ma ścieżkę w argumencie -D.
4. Wejdź do katalogu danych i zorientuj się w układzie: base (dane baz), global (obiekty klastra), pg_wal (dziennik WAL), log lub pg_log (logi serwera, jeśli tak skonfigurowane).
5. Zapamiętaj żelazną zasadę: plików w base, global, pg_wal i pg_xact nie edytujesz ani nie kasujesz ręcznie przy działającym serwerze - to prosta droga do uszkodzenia klastra. Ręcznie ruszasz wyłącznie pliki konfiguracyjne.
6. Rozmiar poszczególnych baz sprawdzaj przez SQL, a nie licząc pliki: SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;.

Jak sprawdzić, że zadziałało

Najprostszy dowód, że trafiłeś we właściwy katalog: w PGDATA istnieje plik PG_VERSION z numerem wersji zgodnym z tym, co zwraca SELECT version();. Powiązanie podkatalogów w base z konkretnymi bazami zrobisz zapytaniem SELECT oid, datname FROM pg_database; - numer OID to nazwa podkatalogu. Jeśli edytowałeś konfigurację, potwierdź, że serwer czyta ten sam plik, który zmieniłeś: SHOW config_file; musi wskazywać dokładnie tę ścieżkę. Gdy chcesz sprawdzić, gdzie serwer faktycznie pisze logi (bywa, że w innym miejscu niż PGDATA), użyj SHOW log_directory; razem z SHOW logging_collector; - jeśli kolektor jest wyłączony, logi mogą trafiać do dziennika systemowego zamiast do pliku.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5