Przywracanie PostgreSQL bez backupu 2.5 TB

Odzyskiwanie PostgreSQL bez kopii zapasowych: case study klastra 2.5 TB

Klaster PostgreSQL od Postgres Professional o pojemności 2.5 TB działał przez trzy lata bez kopii zapasowych na maszynie wirtualnej. Dysk bez rezerwacji miejsca przekroczył fizyczny rozmiar hosta, rozrastając się zgodnie z zasadą copy-on-write. Dziesięć aktywnych baz danych, w tym 1C, uległo awarii po załadowaniu nowej bazy informacyjnej: logi WAL wypełniły dysk hipernadzorcy, punkty kontrolne nie zostały zakończone.

Administratorzy ręcznie usunęli WAL, próbowali zatrzymać postmaster w trybie fast, lecz bezskutecznie. Wymuszone zatrzymanie SIGKILL doprowadziło do uszkodzenia danych z powodu ogromnego shared_buffers. Uruchomienie przez pg_resetwal wyłączyło odzyskiwanie WAL, ale proste zapytania działały, złożone — nie.

Diagnostyka i pierwsze poprawki

Za pomocą narzędzia crash_info (dostępnego w darmowej wersji Postgres Professional) poprzez sygnał SIGRTMIN+6 wykryto zawieszenie na _bt_moveright w indeksie B-tree katalogu systemowego. Włączono parametr ignore_system_indexes lub zastosowano poprawkę do obejścia indeksów systemowych. REINDEX SYSTEM nie zakończyła się przez noc.

pg_dump zawieszał się podczas pobierania listy tabel z powodu braku indeksów. Parametr --data-only nie pomógł: narzędzie żądało rozszerzonych statystyk. Poprawka dla pg_dump wykluczyła niepotrzebne zapytania do katalogu systemowego.

Eksport danych i konsekwencje

Po dobie wyeksportowano dane kluczowej bazy do nowego klastra. Zgłoszenie błędu do społeczności PostgreSQL z poprawką (dla wersji 13–17) wskazało problemy pg_dump przy uszkodzonych indeksach. Społeczność odmówiła uznania tego za błąd: bez kopii zapasowych odzyskiwanie nie jest priorytetem.

Klient zakupił wsparcie enterprise Postgres Professional. Alternatywa dla pg_dump — COPY według listy tabel z 1C (50 000 tabel w bazie), generowanej skryptem, bez odwoływania się do katalogu systemowego.

Kluczowe błędy administratorów

• Brak kopii zapasowych i replik.
• Ręczne usuwanie WAL.
• Zatrzymanie postmaster SIGKILL zamiast SIGQUIT.
• Ignorowanie zaleceń dotyczących rezerwacji dysku.
• Zależność od 'instrukcji' bez weryfikacji kopii zapasowych.
• Nieprawidłowy wybór pg_dump bez uwzględnienia uszkodzeń katalogu.

Co ważne

• Bez kopii zapasowych (dumpów, replik) pełne odzyskanie klastra 2.5 TB jest niemożliwe.
• ignore_system_indexes pozwala obejść uszkodzone indeksy systemowe.
• crash_info jest przydatne do zrzutów stanu bez dostępu do konsoli.
• pg_dump jest podatny na uszkodzenia katalogu: użyj --data-only z poprawkami lub COPY.
• SIGKILL postmaster niszczy dane przy dużym shared_buffers.

Lekcje dla DBA

Klaster na 1C wymaga czyszczenia WAL, monitorowania przestrzeni dyskowej i replikacji. Ogromny shared_buffers maskuje problemy aż do katastrofy. Dla 50 000 tabel generuj skrypty COPY z metadanych 1C.

— Editorial Team