Backup trwa zbyt długo - format custom i równoległość

PostgreSQL

Backup trwa zbyt długo - format custom i równoległość

W skrócie

Kopia logiczna to najczęstsza metoda backupu pojedynczej bazy, ale domyślne wywołanie pg_dump potrafi być boleśnie wolne. Pokażemy, jak zmienić format wyjścia i włączyć równoległość, żeby ten sam backup skończył się kilka razy szybciej i zajął znacznie mniej miejsca.

Jak to wygląda w praktyce

Uruchamiasz pg_dump baza > baza.sql i backup trwa godzinami. Powstaje jeden ogromny plik tekstowy, który zjada dysk, a odtworzenie go przez psql jest równie długie. W czasie dumpu jeden rdzeń procesora jest obciążony pod korek, a pozostałe stoją bezczynnie. Gdy baza rośnie, backup przestaje mieścić się w nocnym oknie i zaczyna nachodzić na godziny pracy. Widać wyraźnie, że coś marnujemy.

Dlaczego tak się dzieje

Domyślny format pg_dump to zwykły tekst SQL. Ma trzy wady dla dużych baz. Po pierwsze jest jednowątkowy, więc korzysta tylko z jednego rdzenia. Po drugie nie jest kompresowany, więc plik jest tak duży jak dane w formie tekstowej. Po trzecie odtwarzanie przez psql to sekwencyjne wykonywanie instrukcji, również na jednym wątku i bez możliwości wyboru, co odtworzyć.

Format custom oraz directory to formaty archiwum. Są kompresowane w locie, przechowują spis treści obiektów i pozwalają odtwarzać wybiórczo. Co ważniejsze, format directory zapisuje każdą tabelę do osobnego pliku, dzięki czemu pg_dump może dumpować wiele tabel równolegle. Przy odtwarzaniu narzędzie pg_restore potrafi z formatu custom i directory równolegle ładować dane i budować indeksy na wielu wątkach naraz, co zwykle jest najwolniejszym etapem.

Jak to rozwiązać krok po kroku

1. Zamiast formatu tekstowego użyj custom przez opcję -Fc: pg_dump -Fc baza -f baza.dump. Plik jest od razu skompresowany i gotowy dla pg_restore.
2. Jeśli chcesz zrównoleglić sam dump, wybierz format directory opcją -Fd i dodaj liczbę wątków: pg_dump -Fd -j 4 baza -f katalog_backup. Powstanie katalog z osobnymi plikami na tabele, dumpowanymi równolegle na czterech połączeniach.
3. Dobierz liczbę wątków rozsądnie. Zacznij od liczby rdzeni serwera, ale pamiętaj, że każdy wątek to osobne połączenie i osobne obciążenie dysku. Na produkcji w godzinach ruchu zejdź niżej, żeby dump nie zagłodził aplikacji.
4. Steruj kompresją opcją -Z, na przykład -Z 6 jako rozsądny kompromis. W PostgreSQL 16 i nowszych możesz wskazać także algorytm, na przykład -Z zstd, który daje lepszy stosunek szybkości do rozmiaru niż domyślny gzip.
5. Odtwarzaj równolegle przez pg_restore: pg_restore -j 4 -d nazwa_nowej_bazy baza.dump. Bazę docelową utwórz wcześniej albo dodaj opcję -C, żeby narzędzie stworzyło ją samo.
6. Nie próbuj odtwarzać formatu custom przez psql - to nie jest zwykły tekst SQL, tylko archiwum. Do custom i directory zawsze używaj pg_restore, a format tekstowy zostaw tylko na małe bazy.

Jak sprawdzić, że zadziałało

Zmierz czas obu wywołań poleceniem time i porównaj ze starym backupem tekstowym - przy kilku rdzeniach i kompresji różnica bywa kilkukrotna zarówno w czasie, jak i w rozmiarze pliku. Poprawność archiwum potwierdzisz, wypisując jego spis treści bez odtwarzania: pg_restore -l baza.dump pokaże listę obiektów, co dowodzi, że plik jest kompletny i czytelny. Ostatecznym testem jest odtworzenie na oddzielnej, testowej bazie i sprawdzenie liczby wierszy w kluczowych tabelach zapytaniem SELECT count(*) - zgodność z produkcją oznacza, że backup jest w pełni użyteczny, a nie tylko szybki.

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