Replikacja strumieniowa PostgreSQL a replikacja logiczna

Uważam się za trochę odkrywcę. W pewnych rzeczach. Zazwyczaj zawsze zamawiam to samo jedzenie w znajomej restauracji, bo strach przed rozczarowaniem przewyższa moje obawy przed spróbowaniem czegoś nowego.

I oczywiście głodny człowiek ma tendencję do jedzenia, prawda?

Jednak jeśli chodzi o technologię, w szczególności SQL (PostgreSQL), mam tendencję do potykania się z pełną prędkością (moja definicja eksploracji) w często nieznanych obszarach, z nadzieją na naukę. Czy jest lepszy sposób na naukę niż doświadczenie?

Więc co, u licha, ma wspólnego to gadanie z replikacją logiczną i strumieniową w PostgreSQL?

Jestem kompletnym nowicjuszem w tych dziedzinach z zerową wiedzą. Tak, mam mniej więcej takie samo zrozumienie w tej dziedzinie Postgres, jak w astrofizyce.

Czy wspomniałem, że nie mam żadnej wiedzy?

Dlatego w tym wpisie na blogu postaram się przetrawić różnice w tego typu replikacjach. Bez praktycznego doświadczenia nie mogę obiecać „Bądź wszystkim, koniec wszystkiego ' rękopis do replikacji.

Prawdopodobnie inni mniej zorientowani w tej dziedzinie (tacy jak ja) odnieśliby korzyści z tego wpisu na blogu.

Doświadczeni użytkownicy i programiści, którzy przyjeżdżają na przejażdżkę, mam nadzieję, że zobaczymy Cię w komentarzach poniżej.

Kilka podstawowych definicji

W szerokim znaczeniu tego terminu, co oznacza replikacja?

Replikacja zdefiniowana w Wikisłowniku ma to do powiedzenia:

„Proces, w którym obiekt, osoba, miejsce lub pomysł mogą być kopiowane, naśladowane lub powielane”.

Jednak piąta pozycja na liście jest bardziej odpowiednia do tego posta na blogu i uważam, że powinniśmy również na nią spojrzeć:

„(computing) Proces częstego elektronicznego kopiowania jednej bazy danych z jednego komputera lub serwera do bazy danych w innym, dzięki czemu wszyscy użytkownicy dzielą ten sam poziom informacji. Służy do poprawy odporności systemu na awarie”.

Teraz jest coś, w co możemy się dostać. Wzmianka o kopiowaniu danych z jednego serwera lub bazy danych na inny? Jesteśmy teraz na znajomym terytorium...

A więc, dodając to, co wiemy z tej definicji, jakie są definicje replikacji strumieniowej i replikacji logicznej?

Zobaczmy, co ma do zaoferowania Wiki PostgreSQL:

Replikacja strumieniowa:„zapewnia możliwość ciągłego wysyłania i stosowania rekordów WAL XLOG do pewnej liczby serwerów rezerwowych w celu zachowania ich aktualności.

Dokumentacja PostgreSQL zawiera następującą definicję replikacji logicznej:

„Replikacja logiczna to metoda replikacji obiektów danych i ich zmian w oparciu o ich tożsamość replikacji (zwykle klucz podstawowy). Terminu logicznego używamy w przeciwieństwie do replikacji fizycznej, która wykorzystuje dokładne adresy blokowe i replikację bajt po bajcie. "

Rozdział 19.6 Replikacja z oficjalnej dokumentacji jest również pełna gadżetów, więc koniecznie odwiedź to źródło.

Poniżej postaram się przekazać różnice w terminach laika. (Pamiętaj, że jeśli się potknę, jestem nowicjuszem.) To jest ekstremalny przegląd „wysokiego poziomu”.

Replikacja logiczna

„Źródłowa” baza danych tworzy PUBLIKACJĘ za pomocą polecenia CREATE PUBLICATION. (Myślę o tym w prosty sposób jako o „nadawcy”).

Dokumentacja określa go jako wydawcę.

Ta baza danych wydawców zawiera dane, które chcemy replikować. Jednak musimy mieć coś do odtworzenia i tu właśnie pojawia się odpowiednik wydawcy. „Abonent”. Zauważ, że dodałem alternatywną liczbę mnogą, ponieważ z tego, co znalazłem podczas wyszukiwania online, praktyczną konfiguracją jest posiadanie wielu subskrybentów.

„Abonent” (może być również traktowany jako baza danych repliki) tworzy SUBSKRYPCJĘ do „źródłowej” bazy danych (wydawcy) definiującej informacje o połączeniu oraz wszelkie publikacje, które subskrybuje.

Możliwe jest, że subskrybent będzie również wydawcą, tworząc własną PUBLIKACJĘ, którą mogą subskrybować inni subskrybenci.

Co się teraz dzieje?

Wszelkie zmiany danych, które zachodzą u wydawcy, są wysyłane do subskrybenta. Które po wyjęciu z pudełka jest wszystkim, ale można je skonfigurować lub ograniczyć do niektórych operacji (np. WSTAW, AKTUALIZUJ lub USUŃ).

Przykład wysokiego poziomu:

Załóżmy, że aktualizujemy wiersz lub wiele wierszy w określonej tabeli w wydawcy, te aktualizacje i zmiany są replikowane w instancji subskrybenta lub wielu subskrybentów, jeśli ten typ konfiguracji jest zaimplementowany.

Oto kilka rzeczy do zapamiętania, o których warto wspomnieć:

• Konfiguracja wal_level bazy danych wydawcy musi być ustawiona na logiczną.
• Replikacja logiczna nie zawiera żadnych poleceń DDL (języka definicji danych).
• Ze strony Konflikty w dokumentacji:„Replikacja logiczna zachowuje się podobnie do normalnych operacji DML w tym, że dane zostaną zaktualizowane, nawet jeśli zostały zmienione lokalnie w węźle subskrybenta. Jeśli przychodzące dane naruszają jakiekolwiek ograniczenia, replikacja zostanie zatrzymana. jest określany jako konflikt. Podczas replikacji operacji UPDATE lub DELETE brakujące dane nie spowodują konfliktu, a takie operacje zostaną po prostu pominięte."
• Tabele wydawców muszą mieć sposób identyfikowania się (tzw. „tożsamość repliki”), aby prawidłowo replikować operacje DML (UPDATE i DELETE) we wszystkich replikach dla tych wierszy, których dotyczy problem. Jeśli tabela ma klucz podstawowy, jest to ustawienie domyślne (wydaje mi się, że jest to dobry wybór), ale w przypadku braku klucza podstawowego dostępne są inne opcje konfiguracji. Można użyć całego wiersza, jeśli nie istnieje żaden inny klucz kandydujący (określany jako „pełny”), chociaż dokumentacja wspomina, że ​​zazwyczaj nie jest to wydajne rozwiązanie. (Zapoznaj się z sekcją IDENTYFIKACJA REPLIK w dokumentach, aby uzyskać opis niższego poziomu, jak to ustawić)

Ograniczenia

Dokumentacja w rozdziale 31.4. Ograniczenia zawiera kilka kluczowych przypomnień o ograniczeniach, które pominę. Pamiętaj i przejrzyj połączoną stronę powyżej, aby uzyskać dokładny opis.

• Schemat bazy danych i żadne polecenia DDL nie są obsługiwane w replikacji. Sugeruje się, że być może początkowo można użyć pg_dump, ale nadal będziesz musiał samodzielnie zaktualizować wszelkie dalsze zmiany i postępy w schemacie we wszystkich replikach.
• Dane w kolumnach sekwencji zostaną zreplikowane. Ale sama sekwencja odzwierciedlałaby tylko wartość początkową. Do przeczytania, to jest w porządku. Ale jeśli to jest twój cel dla przełączenia awaryjnego, musisz sam zaktualizować aktualną wartość. Dokumenty sugerują tutaj pg_dump.
• Obcinanie nie jest jeszcze obsługiwane.
• Replikacja dużych obiektów nie jest obsługiwana.
• Widoki, widoki zmaterializowane, tabele główne partycji lub tabele obce nie są obsługiwane ani przez wydawcę, ani subskrybenta.

Zgłoszone typowe przypadki użycia

• Interesują Cię tylko niektóre dane i zmiany danych, które faktycznie replikujesz, a nie tylko replikacja całej bazy danych.
• Gdy potrzebujesz replik do operacji tylko do odczytu, takich jak scenariusz analityczny.
• Zezwalanie użytkownikom lub różnym podzbiorom użytkowników na ograniczony lub monitorowany dostęp do danych.
• Dystrybucja danych.
• Kompatybilność z innymi wersjami PostgreSQL.

Replikacja strumieniowa

Od badania, czytania i studiowania replikacji strumieniowej, jedną rzeczą, którą zbieram od razu, jest wybór konfiguracji replikacji asynchronicznej (domyślnie) lub synchronicznej.

Ach, bardziej nieznane terminy, co?

Oto moja „wysokopoziomowa” definicja obu:

W przypadku replikacji asynchronicznej po zatwierdzeniu transakcji na serwerze podstawowym występuje niewielkie opóźnienie, gdy ta sama transakcja zostanie zatwierdzona i zapisana w replice. Taka konfiguracja może spowodować utratę danych.

• Po pierwsze, załóżmy, że master się zawiesza.
• Po drugie, repliki są tak daleko w tyle za wzorcem, że odrzuciły potrzebne dane i informacje, aby replika (repliki) była nawet „aktualna”.

Jednak w przypadku replikacji synchronicznej żadna transakcja nie jest uznawana za zakończoną, dopóki nie zostanie potwierdzona przez serwer (serwery) główny i replikę. Który napisze zatwierdzenie do WAL obu serwerów.

Z punktu widzenia rozumiem, oznacza to, że zapisy na wzorcu również zostały potwierdzone i zapisane na replice.

Oto oficjalne wyjaśnienie z sekcji 26.2.8. Synchronous Replication w oficjalnej dokumentacji:

„Przy żądaniu replikacji synchronicznej każde zatwierdzenie transakcji zapisu będzie czekać na potwierdzenie, że zatwierdzenie zostało zapisane w dzienniku zapisu z wyprzedzeniem na dysku zarówno serwera podstawowego, jak i zapasowego. „

Inny fragment dokumentacji zawiera ładne podsumowanie tego, co musi być (moim zdaniem) ogromną korzyścią:„Jedyną możliwością utraty danych jest to, że zarówno główny, jak i zapasowy ulegną awarii w tym samym czasie.”

Chociaż nie ma rzeczy niemożliwych, jest to całkiem dobra pewność, że nie zostaniesz bez kopii swoich danych.

OK, wiemy, że musimy wybrać jedną z tych konfiguracji, ale jaki jest ogólny sens?

W skrócie, Streaming Replication wysyła i stosuje pliki WAL (rejestr zapisu z wyprzedzeniem) z jednego serwera bazy danych (głównego lub głównego) do „repliki” (bazy danych odbierającej).

Ale jest tu pewne zastrzeżenie, o którym należy pamiętać. Potencjalnie pliki WAL z mastera można poddać recyklingowi, zanim otrzyma je standary. Jednym ze sposobów na złagodzenie tego jest zwiększenie ustawienia wal_keep_segments do wyższej wartości.

Punkty na replikację strumieniową

• Domyślnie replikacja strumieniowa jest asynchroniczna, co oznacza, że ​​istnieje opóźnienie (może być niewielkie) między zatwierdzonymi transakcjami w urządzeniu głównym a ich widocznością w replice.
• Repliki łączą się z masterem przez połączenie sieciowe.
• Uważaj na uwierzytelnianie. Zobacz tutaj z dokumentacji:„Bardzo ważne jest, aby uprawnienia dostępu do replikacji były ustawione tak, aby tylko zaufani użytkownicy mogli czytać strumień WAL, ponieważ łatwo jest wydobyć z niego uprzywilejowane informacje”

Kiedy używać replikacji strumieniowej

• Powszechne zastosowanie (zwłaszcza w analityce) zapewnia replikę „tylko do odczytu”, aby odciążyć główny serwer.
• Potrzebujesz środowiska o wysokiej dostępności.
• Przydatna konfiguracja przełączania awaryjnego na serwer gotowości w przypadku awarii głównego serwera.