TL;DR :Replikacja logiczna wysyła zmiany wiersz po wierszu, replikacja fizyczna wysyła zmiany bloków dysku. Replikacja logiczna jest lepsza w przypadku niektórych zadań, a fizyczna w przypadku innych.
Zauważ, że w PostgreSQL 12 (obecnym w momencie aktualizacji) replikacja logiczna jest stabilna i niezawodna, ale dość ograniczona. Jeśli zadajesz to pytanie, użyj replikacji fizycznej.
Replikacja strumieniowa może być replikacja logiczna. To wszystko jest trochę skomplikowane.
Wysyłka WAL a przesyłanie strumieniowe
Istnieją dwa główne sposoby przesyłania danych z mastera do repliki w PostgreSQL:
-
Wysyłka WAL lub ciągła archiwizacja , gdzie poszczególne pliki dziennika zapisu z wyprzedzeniem są kopiowane z
pg_xlogprzezarchive_commandbieganie na wzorcu do innej lokalizacji.restore_commandskonfigurowane w plikurecovery.confrepliki działa na replice, aby pobrać archiwa, dzięki czemu replika może odtworzyć WAL.To jest używane do replikacji do punktu w czasie (PITR), który jest używany jako metoda ciągłego tworzenia kopii zapasowych.
Nie jest wymagane bezpośrednie połączenie sieciowe z serwerem głównym. Replikacja może mieć duże opóźnienia, zwłaszcza bez
archive_timeoutustawić. Wysyłka WAL nie może być używana do replikacji synchronicznej. -
replikacja strumieniowa , gdzie każda zmiana jest wysyłana do co najmniej jednego serwera replik bezpośrednio przez połączenie TCP/IP, gdy to się dzieje. Repliki muszą mieć bezpośrednie połączenie sieciowe, które master skonfigurował w ich
recovery.confprimary_conninfoopcja.Replikacja strumieniowa ma niewielkie opóźnienie lub nie ma go wcale, o ile replika jest wystarczająco szybka, aby nadążyć. Może być używany do replikacji synchronicznej . Nie można używać replikacji strumieniowej dla PITR, więc nie jest ona zbyt przydatna do ciągłego tworzenia kopii zapasowych. Jeśli upuścisz tabelę na master, ups, zostanie ona również upuszczona na repliki.
Tak więc te dwie metody mają różne cele.
Asynchroniczne a synchroniczne przesyłanie strumieniowe
Do tego dochodzi synchroniczny i asynchroniczne replikacja strumieniowa:
-
W asynchronicznej replikacji strumieniowej replika (repliki) może pozostać w tyle za masterem w czasie, gdy master jest szybszy/bardziej zajęty. Jeśli master ulegnie awarii, możesz utracić dane, które nie zostały jeszcze zreplikowane.
Jeśli replika asynchroniczna jest zbyt daleko za masterem, master może wyrzucić informacje, których potrzebuje replika, jeśli
max_wal_size(wcześniej nazywanywal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master'spg_wal(waspg_xlog) może się zapełnić i zatrzymać pracę mastera, dopóki miejsce na dysku nie zostanie zwolnione, jeślimax_wal_sizejest za wysoko lub używane jest gniazdo. -
W replikacji synchronicznej master nie kończy zatwierdzania, dopóki replika nie potwierdzi, że otrzymała transakcję. Nigdy nie tracisz danych, jeśli master ulegnie awarii i musisz przełączyć się na replikę. Master nigdy nie wyrzuci danych, których potrzebuje replika, ani nie wypełni swojego xloga i zabraknie miejsca na dysku z powodu opóźnień repliki. W zamian może to spowodować spowolnienie lub nawet zatrzymanie pracy mastera, jeśli repliki mają problemy, i zawsze ma to pewien wpływ na wydajność mastera z powodu opóźnień w sieci.
Gdy istnieje wiele replik, tylko jedna jest synchroniczna na raz. Zobacz
synchronous_standby_names.
Nie możesz mieć synchronicznego wysyłania dzienników.
W rzeczywistości można połączyć wysyłanie dziennika i replikację asynchroniczną, aby zabezpieczyć się przed koniecznością ponownego tworzenia repliki, jeśli zostanie ona zbyt daleko w tyle, bez ryzyka wpływu na mastera. Jest to idealna konfiguracja dla wielu wdrożeń, połączona z monitorowaniem, jak daleko replika znajduje się za urządzeniem głównym, aby upewnić się, że mieści się w dopuszczalnych granicach odzyskiwania po awarii.
Logiczne a fizyczne
Oprócz tego tego mamy logiczne a fizyczne replikacja strumieniowa wprowadzona w PostgreSQL 9.4:
-
W fizycznej replikacji strumieniowej zmiany są wysyłane prawie na poziomie bloku dysku, na przykład "na offsecie 14 strony dysku 18 relacji 12311, napisała krotka z wartością szesnastkową 0x2342beef1222....".
Fizyczna replikacja wysyła wszystko :zawartość każdej bazy danych w instalacji PostgreSQL, wszystkie tabele w każdej bazie danych. Wysyła wpisy indeksu, wysyła całe nowe dane tabeli, gdy
VACUUM FULL, wysyła dane dla transakcji, które zostały wycofane itp. Generuje więc dużo „szumów” i wysyła dużo nadmiarowych danych. Wymaga również, aby replika była całkowicie identyczna, więc nie można zrobić niczego, co wymagałoby transakcji, na przykład tworzenia tabel tymczasowych lub niezalogowanych. Zapytanie o replikę opóźnia replikację, więc długie zapytania dotyczące repliki muszą zostać anulowane.
W zamian zastosowanie zmian w replice jest proste i wydajne, a replika jest niezawodnie dokładnie taka sama jak master. DDL jest replikowany w sposób przezroczysty, tak jak wszystko inne, więc nie wymaga specjalnej obsługi. Może również przesyłać strumieniowo duże transakcje w miarę ich występowania, więc opóźnienie między zatwierdzeniem w urządzeniu głównym a zatwierdzeniem w replice jest niewielkie, nawet w przypadku dużych zmian.
Fizyczna replikacja jest dojrzała, dobrze przetestowana i powszechnie stosowana.
- logiczna replikacja strumieniowa , nowość w wersji 9.4, wysyła zmiany na wyższym poziomie i znacznie bardziej selektywnie.
Replikuje tylko jedną bazę danych na raz. Wysyła tylko zmiany wierszy i tylko dla zatwierdzonych transakcji i nie musi wysyłać danych próżniowych, zmian indeksów itp. Może selektywnie wysyłać dane tylko dla niektórych tabel w bazie danych. To sprawia, że replikacja logiczna dużo bardziej wydajna przepustowość.
Działanie na wyższym poziomie oznacza również, że możesz dokonywać transakcji na bazach replik. Możesz tworzyć tabele tymczasowe i niezalogowane. Nawet normalne stoły, jeśli chcesz. Możesz używać zewnętrznych opakowań danych, widoków, tworzyć funkcje, cokolwiek chcesz. Nie ma potrzeby anulowania zapytań, jeśli trwają zbyt długo.
Replikacja logiczna może być również wykorzystana do zbudowania replikacji z wieloma wzorcami w PostgreSQL, co nie jest możliwe przy użyciu replikacji fizycznej.
W zamian jednak nie może (obecnie) przesyłać strumieniowo dużych transakcji na bieżąco. Musi poczekać, aż się popełnią. Dlatego może wystąpić duże opóźnienie między zatwierdzeniem dużej transakcji na urządzeniu głównym a zastosowaniem go do repliki.
Odtwarza transakcje ściśle w kolejności zatwierdzania, więc małe, szybkie transakcje mogą utknąć za dużą transakcją i być opóźnione przez pewien czas.
DDL nie jest obsługiwane automatycznie. Musisz samodzielnie zsynchronizować definicje tabel między wzorcem a repliką, w przeciwnym razie aplikacja korzystająca z replikacji logicznej musi mieć do tego własne udogodnienia. Poprawa tego może być skomplikowana.
Sam proces wprowadzania jest bardziej skomplikowany niż „napisanie kilku bajtów tam, gdzie mi kazano”. Zajmuje również więcej zasobów w replice niż replikacja fizyczna.
Obecne implementacje replikacji logicznej nie są dojrzałe ani powszechnie przyjęte, ani szczególnie łatwe w użyciu.
Zbyt wiele opcji, powiedz mi, co mam zrobić
Uff. Skomplikowane, co? I nawet nie wszedłem w szczegóły opóźnionej replikacji, slotów, max_wal_size , osie czasu, jak działa promocja, Postgres-XL, BDR i multimaster itp.
Więc co powinieneś zrobić? ?
Nie ma jednej właściwej odpowiedzi. W przeciwnym razie PostgreSQL wspierałby tylko ten jeden sposób. Istnieje jednak kilka typowych przypadków użycia:
Do tworzenia kopii zapasowych i odzyskiwania po awarii użyj pgbarman do tworzenia podstawowych kopii zapasowych i przechowywania WAL, zapewniając łatwe w zarządzaniu ciągłe tworzenie kopii zapasowych. Nadal powinieneś brać okresowo pg_dump kopie zapasowe jako dodatkowe ubezpieczenie.
Dla wysokiej dostępności przy zerowym ryzyku utraty danych użyj strumieniowej replikacji synchronicznej.
Dla wysokiej dostępności przy niskim ryzyku utraty danych i lepszej wydajności powinieneś używać asynchronicznej replikacji strumieniowej. Włącz archiwizację WAL na potrzeby awaryjne lub użyj gniazda replikacji. Monitoruj, jak daleko replika znajduje się za masterem za pomocą zewnętrznych narzędzi, takich jak Icinga.
Referencje
- ciągła archiwizacja i PITR
- wysoka dostępność, równoważenie obciążenia i replikacja
- ustawienia replikacji
- recovery.conf
- pgbarman
- repmgr
- wiki:replikacja, klastrowanie i łączenie połączeń
