Jak zmigrować bazę między wersjami przez replikację logiczną

PostgreSQL

Jak zmigrować bazę między wersjami przez replikację logiczną

W skrócie

Aktualizacja między wersjami głównymi PostgreSQL zmienia format katalogu danych, więc nie da się jej zrobić przez zwykłe skopiowanie plików. Replikacja logiczna daje najmniej inwazyjną drogę: pozwala trzymać stary i nowy serwer w synchronizacji na żywo i przełączyć się niemal bez przestoju. Pokażemy, jak przeprowadzić taką migrację krok po kroku.

Jak to wygląda w praktyce

Stoisz przed uaktualnieniem produkcji z wersji starszej na nowszą i każda znana metoda ma wadę. Zrzut i odtworzenie przez pg_dump i pg_restore działa, ale przy dużej bazie oznacza wiele godzin, w których aplikacja jest wyłączona. Narzędzie pg_upgrade jest szybsze, ale i tak wymaga zatrzymania serwera na czas operacji, a wycofanie zmiany bywa kłopotliwe. Tymczasem wymagania biznesowe mówią "maksymalnie kilka minut przerwy". Właśnie tu wchodzi replikacja logiczna: pozwala zbudować nowy serwer obok starego, zsynchronizować dane w tle bez zatrzymywania produkcji i przełączyć ruch dopiero wtedy, gdy nowa baza jest gotowa i zgodna, skracając realny przestój do samego przepięcia aplikacji.

Dlaczego tak się dzieje

Replikacja logiczna przenosi zmiany na poziomie wierszy, a nie surowych bloków WAL, więc nie zależy od formatu fizycznego katalogu danych. To dlatego działa między różnymi wersjami głównymi: wydawca na starszej wersji może wysyłać zmiany do subskrybenta na nowszej. Migracja przez replikację logiczną korzysta z tego wprost - budujesz docelową bazę w nowej wersji, kopiujesz do niej strukturę, włączasz subskrypcję, która najpierw wykonuje wstępną synchronizację istniejących danych, a potem na bieżąco dokłada każdą nową zmianę ze starego serwera. Trzeba tylko pamiętać o ograniczeniach tego mechanizmu: nie replikuje automatycznie zmian schematu (DDL), nie przenosi wartości sekwencji ani dużych obiektów w starym formacie, a replikowane tabele muszą mieć jednoznaczny klucz. Te braki domyka się ręcznie tuż przed i po przełączeniu.

Jak to rozwiązać krok po kroku

1. Postaw nowy serwer w docelowej wersji PostgreSQL. Na starym ustaw wal_level na logical i zrestartuj, jeśli był niższy.
2. Przenieś na nowy serwer sam schemat bez danych (np. pg_dump --schema-only i odtworzenie), żeby struktura tabel po obu stronach się zgadzała.
3. Na starym serwerze utwórz publikację obejmującą migrowane tabele (CREATE PUBLICATION), a na nowym subskrypcję do niej (CREATE SUBSCRIPTION). Subskrypcja uruchomi wstępną kopię danych, a potem strumień zmian.
4. Poczekaj, aż wstępna synchronizacja się zakończy i opóźnienie spadnie do minimum. Kontroluj postęp w pg_stat_subscription na nowym serwerze.
5. Zaplanuj krótkie okno przełączenia: wstrzymaj zapisy na starym serwerze, upewnij się, że ostatnie zmiany dotarły do nowego, i przełącz aplikację na nowe połączenie.
6. Ręcznie ustaw wartości sekwencji na nowym serwerze, bo replikacja logiczna ich nie przenosi - inaczej dostaniesz kolizje kluczy przy pierwszych zapisach.
7. Po potwierdzeniu, że nowy serwer działa, usuń subskrypcję i publikację, a stary serwer zatrzymaj i zachowaj jako awaryjny punkt wycofania na kilka dni.

Jak sprawdzić, że zadziałało

Przed przełączeniem potwierdź w pg_stat_subscription, że subskrypcja jest aktywna i opóźnienie jest bliskie zeru. Porównaj liczności kluczowych tabel po obu stronach, żeby wykluczyć luki po wstępnej synchronizacji. Sprawdź, że sekwencje na nowym serwerze wskazują wartości wyższe niż największe istniejące klucze - najprościej wstawiając testowy wiersz i upewniając się, że nie ma kolizji. Po przełączeniu obserwuj aplikację i log nowego serwera pod kątem błędów zapisu. Jeśli aplikacja pisze i czyta bez błędów, dane się zgadzają, a sekwencje nie kolidują, migracja się powiodła.

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