Opis replikacji i dekodowania logicznego

Ukończone

Parametr wal_level umożliwia zdefiniowanie, ile informacji należy zapisać w dzienniku. Dostępne są dwie opcje: LOGICZNA lub REPLIKA. Replika jest wartością domyślną. Ten parametr jest ustawiany podczas uruchamiania serwera.

Wysoka dostępność

Wysoka dostępność to usługa Azure Database for PostgreSQL, która zapewnia serwer rezerwowy gotowy do przejęcia w przypadku awarii na serwerze na żywo. Wysoka dostępność na serwerze elastycznym usługi Azure Database for PostgreSQL używa replikacji do automatycznego aktualizowania serwera rezerwowego przy użyciu zmian danych.

Podczas konfigurowania wysokiej dostępności serwera elastycznego usługi Azure Database for PostgreSQL serwer podstawowy jest umieszczany w jednej strefie dostępności, a serwer rezerwowy jest tworzony w innej strefie dostępności. Dane są replikowane z serwera podstawowego do serwera rezerwowego przy użyciu replikacji przesyłania strumieniowego PostgreSQL w trybie synchronicznym.

Każda strefa dostępności składa się z co najmniej jednego centrum danych. Strefy dostępności mają własne zasilacze, systemy chłodzenia, infrastrukturę sieci itp., co czyni je niezależnymi od siebie. Trzy kopie plików danych i pliki dziennika z wyprzedzeniem zapisu (WAL) są przechowywane w lokalnie nadmiarowym magazynie w każdej strefie dostępności, zapewniając fizyczną izolację między serwerami podstawowymi i rezerwowymi. Jeśli jedna strefa dostępności nie powiedzie się, pozostałe dwie prawdopodobnie będą nadal działać. Strefy dostępności w regionie są połączone przez szybkie sieci fibre z opóźnieniem rundy mniejszym niż 2 milisekundy.

Uwaga

Nie wszystkie regiony mają strefy dostępności.

Dzięki wysokiej dostępności dane są duplikowane przez cały czas, gdy baza danych jest używana, zapewniając aktualną kopię oryginału. Jeśli wystąpi awaria, replika może być używana zamiast oryginału. Replikacja ma serwer podstawowy i serwer rezerwowy. Serwer podstawowy wysyła pliki dziennika WAL do serwera rezerwowego, który odbiera pliki dziennika WAL.

Serwer rezerwowy raportuje z powrotem do serwera podstawowego z informacjami, takimi jak ostatni dziennik z wyprzedzeniem zapisu, który zapisał, oraz ostatnią pozycję opróżnioną na dysk itp. Aby zdefiniować minimalną częstotliwość wysyłania raportu przez odbiornik WAL, ustaw parametr wal_receiver_status_interval . Parametr max_replication_slots definiuje maksymalną liczbę miejsc replikacji, które może obsługiwać serwer. Jeśli wal_level jest ustawiona na WARTOŚĆ REPLICA, max_replication_slots musi być co najmniej jeden, jednak dozwolony zakres wartości wynosi od 0 do 262 143.

Parametr max_wal_senders ustawia maksymalną liczbę procesów nadawcy WAL.

Serwery podstawowe i rezerwowe są monitorowane, a odpowiednie działania są podejmowane w celu rozwiązania problemów, w tym wyzwolenia trybu failover na serwerze rezerwowym. Poniżej przedstawiono listę strefowo nadmiarowych stanów wysokiej dostępności:

• Inicjowanie — w procesie tworzenia nowego serwera rezerwowego.
• Replikowanie — replikacja danych jest w stanie stałym i w dobrej kondycji.
• W dobrej kondycji — rezerwa jest aktualizowana przez element podstawowy.
• Przełączanie w tryb failover — podstawowy serwer bazy danych jest w trakcie przechodzenia w tryb failover do trybu wstrzymania.
• Usuwanie wstrzymania — w procesie usuwania serwera rezerwowego.
• Nie włączono — wysoka dostępność strefowo nadmiarowa nie jest włączona.

Wysoką dostępność można dodać do istniejącego serwera bazy danych. Jeśli włączasz lub wyłączasz wysoką dostępność na serwerze na żywo, wykonaj operację, gdy jest mało aktywności.

Z witryny Azure Portal:

1. Przejdź do serwera usługi Azure Database for PostgreSQL.
2. W sekcji Przegląd wybierz bieżącą konfigurację. Zostanie wyświetlona sekcja Obliczenia i magazyn .
3. W obszarze Wysoka dostępność zaznacz pole wyboru Wysoka dostępność (strefowo nadmiarowa), aby włączyć wysoką dostępność. Wysoka dostępność nie jest obsługiwana w przypadku warstwy z możliwością rozszerzenia.

Należy pamiętać, że wysoka dostępność jest opcją odzyskiwania po awarii. Nie można używać serwera rezerwowego do żadnego innego celu, takiego jak zezwolenie na dostęp do baz danych tylko do odczytu. Można jednak skonfigurować replikację między dwoma serwerami usługi Azure Database for PostgreSQL przy użyciu modelu wydawcy i subskrybenta. Ta konfiguracja utrzymuje dwa serwery z replikowanymi między nimi danymi. Następnie masz pełny dostęp do serwera subskrybenta i możesz używać baz danych do dowolnego celu. Przećwicz tę konfigurację w ćwiczeniu na końcu tego modułu.

Dekodowanie logiczne

Dekodowanie logiczne używa również danych wysyłanych do dziennika z wyprzedzeniem zapisu. Jak sugeruje nazwa, dekoduje wpisy w dzienniku z wyprzedzeniem zapisu, aby były zrozumiałe. Wszystkie zmiany INSERT, UPDATE i DELETE są dostępne dla dekodowania logicznego.

Dekodowanie logiczne może służyć do inspekcji, analizy lub innego powodu, dla którego warto wiedzieć, co się zmieniło, i kiedy uległa zmianie.

Dekodowanie logiczne wyodrębnia zmiany ze wszystkich tabel w bazie danych. Różni się ona od replikacji, ponieważ nie może wysyłać tych zmian do innych wystąpień postgreSQL. Zamiast tego rozszerzenie PostgreSQL udostępnia wtyczkę wyjściową do przesyłania strumieniowego zmian.

Dekodowanie logiczne umożliwia dekodowanie zawartości dziennika z wyprzedzeniem zapisu w łatwym do zrozumienia formacie, który można interpretować bez znajomości struktury bazy danych. Usługa Azure Database for PostgreSQL obsługuje dekodowanie logiczne przy użyciu rozszerzenia wal2json zainstalowanego na serwerach usługi Azure Database for Postgres.

Można użyć innych rozszerzeń, takich jak rozszerzenie pglogical, które umożliwia replikację przesyłania strumieniowego logicznego.

Aby użyć dekodowania logicznego, w obszarze Parametry serwera ustaw:

• wal_level do LOGICZNEJ
• max_replication_slots = 10
• max_wal_senders = 10

Po wprowadzeniu tych zmian należy ponownie uruchomić serwer.

Aby użyć rozszerzenia pglogical w witrynie Azure Portal:

1. Przejdź do serwera usługi Azure Database for PostgreSQL.
2. Wybierz pozycję Parametry serwera i wyszukaj shared_preload_libraries. W polu listy rozwijanej wybierz pozycję pglogical.
3. Wyszukaj ciąg azure.extensions. W polu listy rozwijanej wybierz pozycję pglogical.
4. Aby zastosować zmiany, uruchom ponownie serwer.

Musisz również przyznać administratorowi uprawnienia użytkownika do replikacji:

ALTER ROLE <adminname> WITH REPLICATION;

Aby uzyskać więcej informacji, zapoznaj się z dokumentacją online rozszerzenia pglogical.

Dekodowanie logiczne generuje zmiany danych jako strumień nazywany miejscem replikacji logicznej.

1. Każde miejsce ma jedną wtyczkę wyjściową, którą można zdefiniować.
2. Każde miejsce zapewnia zmiany tylko z jednej bazy danych, ale baza danych może mieć wiele miejsc.
3. Każda zmiana danych jest zwykle emitowana raz na miejsce.
4. W przypadku ponownego uruchomienia bazy danych PostgreSQL miejsce może ponownie emitować zmiany, które klient musi obsłużyć.
5. Miejsca muszą być monitorowane. Nieskonsumowane miejsca są przechowywane we wszystkich plikach WAL dla tych nieskonsumowanych zmian. Taka sytuacja może prowadzić do zawijania identyfikatora transakcji lub pełnego magazynu.