Role i uprawnienia nie wróciły po odtworzeniu - pg_dumpall --globals

PostgreSQL

Role i uprawnienia nie wróciły po odtworzeniu - pg_dumpall --globals

W skrócie

To jedna z najczęstszych pułapek przy przenoszeniu bazy między serwerami. Backup wygląda na kompletny, dane się odtwarzają, a jednak logowanie nie działa. Wyjaśnimy, dlaczego role znikają i jak zrobić backup, po którym środowisko wstaje w komplecie, razem z użytkownikami i hasłami.

Jak to wygląda w praktyce

Przenosisz bazę na nowy serwer: robisz pg_dump, tworzysz bazę docelową i odtwarzasz dump. Dane są na miejscu, ale aplikacja nie może się zalogować, bo rola, na której działa, nie istnieje. Albo rola istnieje, lecz przy odtwarzaniu poleceń GRANT sypią się błędy role "app_user" does not exist. Ręcznie tworzysz brakujące role, ale wtedy nie znasz ich haseł ani atrybutów, więc i tak trzeba je konfigurować od zera. Robi się z tego droga przez mękę.

Dlaczego tak się dzieje

W PostgreSQL role, ich hasła oraz uprawnienia na poziomie klastra (na przykład CREATEDB czy SUPERUSER) nie należą do żadnej pojedynczej bazy. Są obiektami globalnymi, wspólnymi dla całego klastra i przechowywanymi w katalogu systemowym poza bazami użytkownika. Dlatego pg_dump, który z definicji zrzuca zawartość jednej bazy, ich nie zawiera. W dumpie znajdują się polecenia GRANT odwołujące się do ról po nazwie, ale sama definicja roli i jej hasło pozostają na starym serwerze.

Kiedy odtwarzasz taki dump na świeżym klastrze, w którym tych ról jeszcze nie ma, polecenia GRANT nie mają komu nadać uprawnień. Właściciele tabel również nie mogą zostać ustawieni, bo wskazywana rola nie istnieje. Rozwiązaniem jest oddzielne narzędzie pg_dumpall, które w trybie --globals-only wyciąga właśnie te obiekty globalne dla całego klastra.

Jak to rozwiązać krok po kroku

1. Na starym serwerze wykonaj backup obiektów globalnych: pg_dumpall --globals-only -f globals.sql. Powstanie plik SQL z definicjami wszystkich ról, ich haseł, atrybutów i uprawnień na poziomie klastra oraz definicji tablespace'ów.
2. Osobno zrób backup samej bazy jak zwykle, na przykład pg_dump -Fc baza -f baza.dump. Te dwa pliki uzupełniają się nawzajem.
3. Na nowym serwerze najpierw odtwórz obiekty globalne: psql -f globals.sql postgres. Kolejność jest kluczowa - role muszą istnieć, zanim odtworzysz bazę, która się do nich odwołuje.
4. Dopiero teraz odtwórz bazę: pg_restore -C -d postgres baza.dump. Opcja -C tworzy bazę i od razu ustawia poprawnego właściciela, bo rola już istnieje.
5. Włącz do rutyny osobny backup globalsów. Nawet jeśli codziennie robisz pg_dump baz, dorzuć jedno wywołanie pg_dumpall --globals-only, żeby nie odtwarzać ról ręcznie w kryzysie.
6. Jeśli chcesz zrzucić cały klaster jednym poleceniem, użyj samego pg_dumpall bez flagi - zapisze i globalsy, i wszystkie bazy. Wadą jest format wyłącznie tekstowy i brak równoległości, więc dla dużych baz zostań przy rozdzieleniu na globalsy plus pojedyncze dumpy custom.

Jak sprawdzić, że zadziałało

Po odtworzeniu obiektów globalnych wypisz listę ról poleceniem \du w psql i porównaj ją z listą ze starego serwera - powinny zgadzać się nazwy oraz atrybuty. Poprawność haseł potwierdzisz najlepiej realnym logowaniem rolą aplikacyjną: psql -U app_user -d baza -h nowy_serwer. Jeśli logowanie przechodzi bez ręcznego ustawiania hasła, znaczy że hasło przyjechało w globalsach. Na koniec sprawdź uprawnienia na kluczowej tabeli poleceniem \dp nazwa_tabeli - obecność wpisów GRANT dla właściwych ról dowodzi, że odtworzenie w poprawnej kolejności zadziałało i aplikacja ma pełny dostęp.

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