Streaming PostgreSQL a replikacja logiczna – porównanie

Replikacja informacji przechowywanych w bazie danych jest niezbędna do dystrybucji danych i zapewnienia kopii zapasowej, której można użyć do odzyskiwania po awarii, na wypadek gdyby coś poszło nie tak.

Replikacja PostgreSQL występuje w dwóch formach i obie mają swoje niszowe zastosowania. Zrozumienie, jak zastosować jedną lub obie z tych metod replikacji danych, może usprawnić procesy dystrybucji danych. Ostatnią rzeczą, jakiej chcesz, jest utrata kluczowej pracy wykonanej w bazie danych.

Rzućmy okiem na zalety, wady i przypadki użycia replikacji strumieniowej i logiki w PostgreSQL.

Definiowanie replikacji danych w PostgreSQL

Jeśli wiesz już, czym jest replikacja danych, możesz przejść dalej i przewinąć w dół do następnej sekcji. Ale jeśli jesteś nowicjuszem w inżynierii baz danych, chcemy naprawdę szybko położyć fundament.

Jak sama nazwa wskazuje, replikacja to proces częstego kopiowania danych z jednej bazy danych na serwerze komputerowym do innej bazy danych na innym serwerze, dzięki czemu wszyscy użytkownicy mają dostęp do tego samego poziomu informacji. W informatyce replikacja służy do eliminacji błędów w systemie cyfrowym.

Replikacja eliminuje silosy danych, chroni cenne informacje i usprawnia rozwój.

W PostgreSQL istnieją dwie opcje replikacji:replikacja logiczna i strumieniowa. Te metody są świetne w różnych przypadkach użycia, a jako programista możesz być bardziej skłonny do używania jednej z nich. Ale dobrze jest zrozumieć, jak używać obu, aby móc zdecydować, które zastosować w różnych scenariuszach.

Replikacja logiczna w PostgreSQL

Replikacja strumieniowa została wprowadzona do użytku z PostgreSQL v10.0. Replikacja logiczna polega na kopiowaniu/replikowaniu obiektów danych i ich zmianach na podstawie ich tożsamości replikacji.

W wielu przypadkach tożsamość danych jest kluczem podstawowym. W PostgreSQL zapewnia użytkownikom precyzyjną kontrolę nad replikowanymi danymi i bezpieczeństwem informacji.

Termin logiczny służy do odróżnienia go od replikacji fizycznej, która wykorzystuje replikację bajt po bajcie i dokładne adresy blokowe. Przeczytaj więcej w oficjalnej dokumentacji PostgreSQL tutaj.

Dzięki modelowi publikowania i subskrybowania działa, umożliwiając co najmniej jednemu subskrybentowi subskrybowanie jednej lub większej liczby publikacji w węźle wydawcy. Subskrybenci mogą pobierać informacje z publikacji i ponownie publikować dane w celu kaskadowej replikacji lub bardziej złożonej konfiguracji.

Replikacja danych logicznych może również przybrać formę replikacji transakcyjnej. Jeśli inżynier chce skopiować tabelę, może użyć tej metody replikacji, aby zrobić migawkę danych po stronie wydawcy i wysłać ją do bazy danych subskrybenta.

Gdy subskrybenci wprowadzają zmiany w oryginalnych danych, baza danych wydawców otrzymuje aktualizacje w czasie rzeczywistym. Aby zapewnić spójność transakcyjną publikacji z pojedynczą subskrypcją, subskrybent musi zastosować dane w tej samej kolejności co wydawca.

Zalety replikacji logicznej w PostgreSQL

Replikacja logiczna umożliwia użytkownikom korzystanie z serwera docelowego do zapisu i umożliwia programistom korzystanie z różnych indeksów i definicji zabezpieczeń. Zapewnia to większą elastyczność przesyłania danych między wydawcami a subskrybentami.

Obsługa różnych wersji

Dodatkowo posiada wsparcie dla wielu wersji i może być ustawiany pomiędzy różnymi wersjami PostgreSQL. Zapewnia również filtrowanie oparte na zdarzeniach. Publikacje mogą mieć kilka subskrypcji, co ułatwia udostępnianie danych w szerokiej sieci.

Minimalne obciążenie serwera

W porównaniu z rozwiązaniami opartymi na wyzwalaczach ma minimalne obciążenie serwera, a jednocześnie zapewnia elastyczność pamięci masowej dzięki replikowaniu mniejszych zestawów. Jak wspomniano powyżej, replikacja danych logicznych może nawet kopiować dane zawarte w podstawowych tabelach podzielonych na partycje.

Należy również wspomnieć, że logiczna replikacja danych umożliwia transformację danych, nawet gdy jest konfigurowana, i umożliwia równoległe przesyłanie strumieniowe między wydawcami.

Wady replikacji logicznej w PostgreSQL

Replikacja logiczna nie kopiuje sekwencji, dużych obiektów, widoków zmaterializowanych, tabel głównych partycji ani tabel obcych.

W PostgreSQL replikacja danych logicznych jest obsługiwana tylko przez operacje DML. Deweloperzy nie mogą używać DDL ani obcinać, a schemat musi być wcześniej zdefiniowany. Dodatkowo nie obsługuje wzajemnej (dwukierunkowej) replikacji.

Jeśli użytkownicy napotkają konflikty z ograniczeniami replikowanych danych w tabeli, replikacja zostanie zatrzymana. Jedynym sposobem wznowienia replikacji jest rozwiązanie przyczyny konfliktu.

Niezamierzony konflikt może zatrzymać rozwój Twojego zespołu, więc musisz wiedzieć, jak szybko rozwiązywać wszelkie problemy.

Jeśli konflikt nie zostanie szybko rozwiązany, gniazdo replikacji zawiesi się w obecnym stanie, węzeł wydawcy zacznie gromadzić dzienniki zapisu z wyprzedzeniem (WAL), a w węźle ostatecznie zabraknie miejsca na dysku.

Przypadki użycia dla replikacji logicznej w PostgreSQL

Wielu inżynierów używa replikacji logicznej do:

• Dystrybucja zmian w obrębie pojedynczej bazy danych lub podzbioru bazy danych do subskrybentów w czasie rzeczywistym
• Łączenie wielu baz danych w jedną centralną bazę danych (często do użytku analitycznego)
• Tworzenie replikacji w różnych wersjach PostgreSQL
• Wdrażanie replikacji między instancjami PostgreSQL na różnych platformach, takich jak Linux na Windows
• Udostępnianie replikowanych danych innym użytkownikom lub grupom
• Dystrybucja podzbioru bazy danych między wieloma bazami danych

Replikacja strumieniowa w PostgreSQL

Replikacja strumieniowa została wprowadzona do użytku z PostgreSQL 9.0. Proces wysyła i stosuje pliki rejestrowania z wyprzedzeniem (WAL) z głównego lub podstawowego serwera bazy danych do repliki lub odbierającej bazy danych. Warstwy WAL są używane do replikacji i zapewnienia integralności danych.

Jak działa replikacja strumieniowa

Replikacja strumieniowa ma na celu wypełnienie luki między transferami danych nieodłącznie związanymi z przesyłaniem dziennika opartego na plikach, który czeka, aż warstwa WAL osiągnie maksymalną pojemność do przesyłania danych.

Poprzez przesyłanie strumieniowe rekordów WAL serwery baz danych przesyłają strumieniowo rekordy WAL w kawałkach, aby zsynchronizować dane. Serwer rezerwowy łączy się z repliką i odbiera fragmenty WAL podczas ich przesyłania.

W przypadku replikacji strumieniowej użytkownik musi zdecydować, czy skonfigurować replikację asynchroniczną, czy synchroniczną. Kiedy replikacja strumieniowa jest początkowo wdrażana, domyślnie będzie to replikacja asynchroniczna.

Wskazuje to, że istnieje opóźnienie między początkową zmianą w podstawowym a odzwierciedleniem tej zmiany w replice. Asynchronizacja otwiera drzwi do potencjalnej utraty danych, jeśli master ulegnie awarii przed skopiowaniem zmian lub jeśli replika jest tak niezsynchronizowana z oryginałem, że odrzuciła już istotne dane w celu wprowadzenia zmian.

Replikacja synchroniczna jest znacznie bezpieczniejszą opcją, ponieważ wprowadza zmiany w czasie rzeczywistym. Transfer z mastera do repliki jest uważany za niekompletny, dopóki oba serwery nie zweryfikują informacji. Po potwierdzeniu zmian danych transfer jest rejestrowany na obu serwerach WAL.

Niezależnie od tego, czy używasz replikacji asynchronicznej, czy synchronicznej, repliki muszą być połączone z systemem głównym za pośrednictwem połączenia sieciowego. Ponadto użytkownicy muszą skonfigurować uprawnienia dostępu do strumieni WAL repliki, aby informacje nie zostały naruszone.

Zalety replikacji strumieniowej w PostgreSQL

Jedną z najważniejszych zalet korzystania z replikacji strumieniowej jest to, że jedynym sposobem na utratę danych jest awaria serwera głównego i serwera odbierającego w tym samym czasie. Jeśli przekazujesz ważne informacje, przesyłanie strumieniowe replikacji prawie gwarantuje, że kopia Twojej pracy zostanie zapisana.

Użytkownicy mogą połączyć więcej niż jeden serwer rezerwowy z serwerem podstawowym, a dzienniki będą przesyłane strumieniowo z serwera głównego do każdego z podłączonych serwerów rezerwowych. Jeśli jedna z replik zostanie opóźniona lub zostanie rozłączona, przesyłanie strumieniowe będzie kontynuowane do innych replik.

Skonfigurowanie przesyłania dziennika za pośrednictwem replikacji strumieniowej nie będzie zakłócać działania użytkownika aktualnie uruchomionego w podstawowej bazie danych. Jeśli główny serwer danych musi zostać wyłączony, poczeka, aż zaktualizowane rekordy zostaną wysłane do repliki, zanim wyłączy się.

Wady replikacji strumieniowej w PostgreSQL

Replikacja strumieniowa nie kopiuje informacji do innej wersji lub architektury, nie zmienia informacji o serwerach rezerwowych i nie oferuje replikacji szczegółowej.

Zwłaszcza w przypadku asynchronicznej replikacji danych strumieniowych starsze pliki WAL, które nie są kopiowane do repliki, mogą zostać ponownie wykorzystane, gdy użytkownik dokona zmian w systemie głównym. Aby upewnić się, że ważne pliki nie zostaną utracone, użytkownik może ustawić wyższą wartość wal_keep_segments.

Bez poświadczeń uwierzytelniających użytkownika skonfigurowanych dla serwerów replik, wyodrębnienie poufnych danych może być łatwe. Aby aktualizacje w czasie rzeczywistym miały miejsce między urządzeniem głównym a repliką, użytkownik musi zmienić metodę replikacji z domyślnej replikacji asynchronicznej na replikację synchroniczną.

Przypadki użycia replikacji strumieniowej w PostgreSQL

Wielu inżynierów używa replikacji strumieniowej do:

• Tworzenie kopii zapasowej podstawowej bazy danych na wypadek awarii serwera lub utraty danych
• Promowanie rozwiązania o wysokiej dostępności z jak najmniejszym opóźnieniem replikacji
• Odprowadzanie dużych zapytań w celu zmniejszenia obciążenia systemu podstawowego
• Rozprowadzanie obciążeń bazy danych na kilka komputerów, zwłaszcza w przypadku formatów tylko do odczytu

Co czeka nas w przyszłości?

PostgreSQL Global Development Group ogłosiła wydanie PostgreSQL 14 30 września 2021 r. Nowa wersja została załadowana aktualizacjami zarówno w zakresie replikacji strumieniowej, jak i logicznej za pośrednictwem platformy.

W przypadku replikacji strumieniowej wersja 14 umożliwia użytkownikom:

• Ustaw parametr serwera log_recovery_conflict_waits aby automatycznie zgłaszać długi czas oczekiwania na konflikt odzyskiwania
• Wstrzymaj odzyskiwanie na serwerze w trybie gotowości podczas zmiany parametrów na serwerze podstawowym (zamiast natychmiastowego wyłączania trybu gotowości)
• Użyj funkcji pg_get_wal_replay_pause_state() aby bardziej szczegółowo zgłosić stan przywracania
• Podaj parametr serwera tylko do odczytu in_hot_standby
• Szybko obcinaj małe tabele podczas odzyskiwania w klastrach, które mają dużą liczbę współdzielonych buforów
• Zezwól na synchronizację systemu plików na początku odzyskiwania po awarii przez Linuksa
• Użyj funkcji pg_xact_commit_timestamp_origin() na określonej transakcji, aby zwrócić znacznik czasu zatwierdzenia i źródło replikacji
• Użyj funkcji pg_last_committed_xact() dodać źródło replikacji do zwróconego rekordu
• Zastosuj standardowe funkcje kontroli uprawnień, aby zmienić funkcje źródła replikacji (domyślnie nadal ogranicza dostęp do superużytkowników)

W przypadku replikacji logicznej wersja 14 umożliwia użytkownikom:

• Przesyłaj strumieniowo długie transakcje w toku do subskrybentów za pomocą interfejsu API replikacji logicznej
• Zezwalaj na wiele transakcji podczas replikacji tabeli
• Generuj natychmiastowe podtransakcje WAL-log i powiązania XID najwyższego poziomu
• Użyj funkcji pg_create_logical_replication_slot() w celu ulepszenia interfejsów API dekodowania logicznego dla zatwierdzania dwufazowego
• Dodaj komunikaty unieważniające pamięć podręczną do WAL podczas wykonywania polecenia, aby umożliwić logiczne przesyłanie strumieniowe transakcji w toku
• Kontroluj, które logiczne komunikaty dekodujące są wysyłane do strumienia replikacji
• Użyj trybu transferu binarnego, aby przyspieszyć replikacje
• Filtruj dekodowanie według XID

PostgreSQL pracuje już nad wersją 15, która ma ukazać się w trzecim kwartale 2022 roku. Jednym z problemów dotyczących replikacji, które należy rozwiązać w najnowszej wersji, jest uniemożliwienie używania zmiennych dziedziczonych ze środowiska serwerowego w replikacji strumieniowej. Ale ponieważ coraz więcej użytkowników przystosowuje się do wersji 14, PostgreSQL prawdopodobnie doda więcej zadań w celu ulepszenia funkcji replikacji.

Szybkie porównanie replikacji PostgreSQL:replikacja logiczna i strumieniowa

Wniosek

Mamy nadzieję, że ten przewodnik przyda się podczas konfigurowania funkcji replikacji. Jeśli masz jakieś pytania lub chciałbyś wiedzieć o tym, jak ScaleGrid może Ci pomóc we wdrożeniu PostgreSQL, skontaktuj się z jednym z naszych wielu ekspertów od baz danych.