Replikacja fizyczna czy logiczna - kiedy która

PostgreSQL

Replikacja fizyczna czy logiczna - kiedy która

W skrócie

To najczęstsze rozwidlenie przy projektowaniu wysokiej dostępności i integracji danych w PostgreSQL. Fizyczna i logiczna replikacja wyglądają podobnie z lotu ptaka, ale różnią się fundamentalnie tym, co i jak przenoszą. Zestawimy je wprost i pokażemy, którą wybrać w typowych sytuacjach.

Jak to wygląda w praktyce

Decyzja zwykle zapada pod presją konkretnej potrzeby, a zły wybór wychodzi dopiero później. Ktoś stawia replikację logiczną licząc na pełny failover i odkrywa, że nie replikuje ona automatycznie zmian schematu, sekwencji ani dużych obiektów, a przełączenie wymaga dodatkowej pracy. Ktoś inny wybiera replikację fizyczną, żeby przesłać jedną tabelę do hurtowni na innej wersji PostgreSQL, i orientuje się, że fizyczna działa tylko na cały klaster i tylko między identycznymi wersjami. Trzeci przypadek: potrzebny jest zapisywalny odbiorca (np. dwie aplikacje piszące do wspólnego zbioru), a replikacja fizyczna z zasady daje odbiorcę tylko do odczytu. W każdym z tych scenariuszy problem nie jest w konfiguracji, tylko w wyborze mechanizmu niepasującego do celu.

Dlaczego tak się dzieje

Obie replikacje wyrastają z tego samego dziennika WAL, ale przetwarzają go inaczej. Fizyczna kopiuje surowe zmiany bloków i odtwarza je na standby, tworząc dokładne odbicie primary: te same pliki, ta sama wersja główna, identyczna struktura fizyczna. Dlatego standby obejmuje cały klaster, jest tylko do odczytu i wymaga zgodności wersji, za to jest lekka, szybka i idealna do failoveru. Logiczna dekoduje WAL do operacji na wierszach (wstaw, zmień, usuń) i wysyła je jako zmiany logiczne przez publikacje i subskrypcje. Dzięki temu można wybrać konkretne tabele, mieć różne wersje po obu stronach, dopisywać własne obiekty na odbiorcy i pisać do niego lokalnie. Ceną jest większy narzut, brak automatycznego przenoszenia DDL i sekwencji oraz wymóg, by replikowane tabele miały klucz identyfikujący wiersze.

Jak to rozwiązać krok po kroku

1. Zapisz cel jednym zdaniem. "Chcę gorącą kopię do przełączenia awaryjnego" prowadzi do fizycznej; "chcę wysyłać wybrane tabele do innej bazy" prowadzi do logicznej.
2. Sprawdź warunek wersji. Jeśli obie strony muszą mieć tę samą wersję główną - fizyczna jest w porządku. Jeśli mają się różnić (np. migracja z 15 na 17) - to zadanie dla logicznej.
3. Sprawdź, czy odbiorca ma być zapisywalny. Potrzebny lokalny zapis na replice oznacza replikację logiczną; fizyczny standby jest tylko do odczytu.
4. Sprawdź zakres danych. Cały klaster naraz to fizyczna; wybrane tabele lub schematy to logiczna.
5. Dla failoveru i skalowania odczytów skonfiguruj fizyczną strumieniową: wal_level na poziomie replica, slot replikacyjny i pg_basebackup jako punkt startu standby.
6. Dla integracji i migracji między wersjami skonfiguruj logiczną: wal_level ustawiony na logical, publikację na wydawcy i subskrypcję na odbiorcy, pilnując kluczy głównych w replikowanych tabelach.
7. Jeśli potrzebujesz jednego i drugiego (np. HA fizyczne plus wysyłka wycinka danych na zewnątrz), połącz oba mechanizmy - działają równolegle na tym samym klastrze.

Jak sprawdzić, że zadziałało

Zweryfikuj, że działa dokładnie ten mechanizm, którego chciałeś. Dla fizycznej: pg_stat_replication na primary pokazuje standby w stanie streaming, a próba zapisu na standby jest odrzucana jako baza tylko do odczytu - to potwierdza charakter fizyczny. Dla logicznej: na wydawcy istnieje publikacja i aktywny slot logiczny, a na odbiorcy pg_stat_subscription pokazuje rosnący postęp. Zrób test rozdzielczy: zmień wiersz w tabeli objętej publikacją i potwierdź, że dotarł do odbiorcy, a jednocześnie sprawdź, że tabela spoza publikacji nie jest replikowana. Zgodność faktycznego zachowania z celem to najlepszy dowód trafnego wyboru.

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