Czym jest replikacja? Jakie są rodzaje replikacji? Czym charakteryzują się poszczególne rodzaje replikacji? Czym się różnią poszczególne rodzaje replikacji?
Z tego artykułu dowiesz się:
jakie są rodzaje replikacji i co je cechuje: strumieniowa, WAL shipping, logiczna,
czym się różnią od siebie poszczególne rodzaje replikacji,
czym się różni replikacja synchroniczna od asynchronicznej.
PostgreSQL natywnie wspiera kilka wariantów replikacji, czyli replikowania danych z jednej instancji na innej, lub nawet innych. Wszystkie oparte są o wpisy do plików WAL lub same pliki WAL. -
replikacja fizyczna strumieniowa - inaczej hot standby, która polega na przesyłaniu wszystkich wpisów WAL z instancji źródłowej do repliki i natychmiastowym ich odtwarzaniu. Występuje w dwóch formach, synchronicznej oraz asynchronicznej . W obu dane odtwarzane są na replice tak szybko jak to możliwe. Nawet w replikacji asynchronicznej “lag”, czyli opóźnienie w odtwarzaniu danych na replice, jest tak niskie, że można przyjąć, iż dane dostępne są w tej samej chwili bez żadnego opóźnienia. Replkacja synchroniczna od replikacji asynchronicznej różni się tylko sposobem commitowania transakcji na instancji primary(master). W synchronicznej transakcja na serwerze primary czeka na odtworzenie transakcji na replice przed zwróceniem informacji o poprawnym wykonaniu transakcji, przez co czas potrzebny na wykonanie każdej pojedynczej transakcji wzrasta o minimalnie “roundtrip time”, czyli czas, który pakiet potrzebuje, aby przebyć drogę z serwera primary na replikę i z powrotem. A w replikacji asynchronicznej transakcja jest commitowana w momencie zapisu wpisu do pliku WAL, dzięki czemu możemy osiągnąć wyższą liczbę transakcji na sekundę, kosztem potencjalnej różnicy danych pomiędzy serwerem primary a standby, w przypadku wystąpienia laga replikacji. -
Wadą tego rozwiązania jest to , że w pewnych przypadkach może negatywnie wpływać na wydajność instancji primary, a pozytywną stroną, że dane są w większości przypadków w tej samej postaci.
replikacja fizyczna “log-shipping” - inaczej ciągłe odzyskiwanie, warm standby. Serwer replikowany działający jako “log-shipping” replika wszystkie dane do odtwarzania wczytuje z plików WAL, które pobiera z archiwum WAL. Replikacja taka zawsze jest trochę opóźniona, o przynajmniej jeden plik WAL, ponieważ WALe są archiwizowane dopiero po zamknięciu loga, czyli po całkowitym wypełnieniu go wpisami WAL lub rotacji loga wywołanej w inny sposób - czy to ręcznie, czy parametrem archive_timeout. Plusem takiego rozwiązania jest całkowity brak wpływu takiej repliki na instancję główną postgresa, a wadą jest ciągłe opóźnienie w odtwarzaniu danych, zawsze brakuje nam tych najświeższych.
replikacja logiczna replikacja polegająca na przesyłaniu wpisów WAL z instancji primary na standby, podobnie jak w replikacji fizycznej strumieniowej. Różnica pomiędzy logiczną a fizyczną replikacją polega na sposobie odtwarzania tych wpisów. Fizyczna odtwarza je w dokładnie takiej formie, w jakiej je otrzymała, a logiczna dokonuje operacji rozszyfrowania tego wpisu oraz wyciągnięcia wszystkich operacji DML (INSERT, UPDATE, DELETE, TRUNCATE) z plików WAL w celu ich odtworzenia. Jej konfiguracja wymaga stworzenia dodatkowych struktur w Postgresie, takich jak publikacja (CREATE PUBLICATION) na serwerze primary, określająca, które obiekty powinny być replikowane, oraz subskrypcja (CREATE SUBSCRIPTION) na serwerze repliki, gdzie odtwarzane będą wszystkie zmiany. Największą wadą tego rozwiązania jest brak wsparcia dla replikacji zmian w strukturach obiektów (DDL - czyli wszystkie instrukcje CREATE i ALTER). Chcąc dodać nową kolumnę do tabeli, która jest replikowana, powinniśmy tę kolumnę najpierw utworzyć na serwerze docelowym, replice, a dopiero później na serwerze źródłowym, dzięki czemu unikniemy przerwania replikacji logicznej. Zaletami tego rozwiązania jest możliwość replikacji pomiędzy różnymi wersjami postgresa, przykładowo z wersji 13 do 15, dzięki czemu możemy z niej skorzystać jako alternatywnej metody aktualizacji postgresa do wyższej wersji. Replika może być otwarta również do zapisu, a od wersji 16 możliwa jest konfiguracja środowiska replikowanego “multi-master”, gdzie mamy kilka instancji obsługujących zapis do tych samych tabel i replikujących wszystkie zmiany na pozostałe serwery.
Jakie rodzaje replikacji wspiera natywnie PostgreSQL?
PostgreSQL wspiera replikację fizyczną strumieniową (hot standby), replikację fizyczną typu log-shipping (warm standby) oraz replikację logiczną. Wszystkie opierają się na plikach WAL (dziennik zapisu z wyprzedzeniem, w którym rejestrowane są zmiany) lub na wpisach z tych plików.
Czym różni się replikacja synchroniczna od asynchronicznej?
W replikacji synchronicznej transakcja na serwerze głównym czeka na jej odtworzenie na replice, zanim potwierdzi wykonanie, więc każda transakcja trwa dłużej o czas podróży pakietu tam i z powrotem. W asynchronicznej transakcja jest zatwierdzana już w chwili zapisu do WAL, co daje więcej transakcji na sekundę kosztem możliwej różnicy danych między serwerami.
Na czym polega replikacja log-shipping i jaka jest jej główna wada?
W replikacji log-shipping (warm standby) replika odtwarza dane z gotowych plików WAL pobieranych z archiwum. Jej zaletą jest brak wpływu na serwer główny, ale wadą jest stałe opóźnienie o przynajmniej jeden plik WAL, ponieważ plik jest archiwizowany dopiero po całkowitym wypełnieniu lub po rotacji wymuszonej parametrem archive_timeout.
Czym replikacja logiczna różni się od fizycznej strumieniowej?
Różnica leży w sposobie odtwarzania wpisów. Replikacja fizyczna odtwarza je dokładnie w formie, w jakiej je otrzymała. Logiczna rozszyfrowuje wpisy WAL i wyciąga z nich operacje DML (INSERT, UPDATE, DELETE, TRUNCATE), by odtworzyć je na replice. Logiczna wymaga utworzenia publikacji na serwerze głównym i subskrypcji na replice.
Jakie są zalety i ograniczenia replikacji logicznej?
Zaletą jest możliwość replikacji między różnymi wersjami PostgreSQL, co pozwala użyć jej jako metody aktualizacji, oraz otwarcie repliki do zapisu. Największym ograniczeniem jest brak wsparcia dla replikacji zmian struktury obiektów (DDL) - nową kolumnę trzeba najpierw dodać na replice, a dopiero potem na serwerze źródłowym, aby nie przerwać replikacji.
Komentarze (0)
Brak komentarzy...