Replikacja logiczna i dekodowanie logiczne w usłudze Azure Database for PostgreSQL — serwer elastyczny

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Serwer elastyczny usługi Azure Database for PostgreSQL obsługuje następujące metodologie wyodrębniania i replikacji danych logicznych:

1. Replikacja logiczna

   1. Używanie natywnej replikacji logicznej postgreSQL do replikowania obiektów danych. Replikacja logiczna umożliwia szczegółową kontrolę replikacji danych, w tym replikacji danych na poziomie tabeli.
   2. Korzystanie z rozszerzenia pglogical , które zapewnia replikację przesyłania strumieniowego logicznego i więcej możliwości, takich jak kopiowanie początkowego schematu bazy danych, obsługa truNCATE, możliwość replikowania języka DDL itp.

2. Dekodowanie logiczne implementowane przez dekodowanie zawartości dziennika z wyprzedzeniem zapisu (WAL).

Porównanie replikacji logicznej i dekodowania logicznego

Replikacja logiczna i dekodowanie logiczne mają kilka podobieństw. Oba te elementy:

• Umożliwia replikowanie danych z bazy danych Postgres.

• Użyj dziennika z wyprzedzeniem zapisu (WAL) jako źródła zmian.

• Użyj miejsc replikacji logicznej do wysyłania danych. Miejsce reprezentuje strumień zmian.

• Użyj właściwości REPLICA IDENTITY tabeli, aby określić, jakie zmiany można wysłać.

• Nie replikuj zmian DDL.

Obie technologie mają swoje różnice:

Replikacja logiczna:

• Umożliwia określenie tabeli lub zestawu tabel do replikacji.

Dekodowanie logiczne:

• Wyodrębnia zmiany we wszystkich tabelach w bazie danych.

Wymagania wstępne dotyczące replikacji logicznej i dekodowania logicznego

1. Przejdź do strony parametrów serwera w portalu.

2. Ustaw parametr wal_level serwera na logicalwartość .

3. Jeśli chcesz użyć rozszerzenia pglogical, wyszukaj shared_preload_librariesparametry i i azure.extensions wybierz je pglogical z listy rozwijanej.

4. Zaktualizuj max_worker_processes wartość parametru do co najmniej 16. W przeciwnym razie mogą wystąpić problemy, takie jak WARNING: out of background worker slots.

5. Zapisz zmiany i uruchom ponownie serwer, aby zastosować zmiany.

6. Upewnij się, że elastyczne wystąpienie serwera usługi Azure Database for PostgreSQL zezwala na ruch sieciowy z zasobu łączącego.

7. Udziel uprawnień replikacji użytkownika administratora.

   ALTER ROLE <adminname> WITH REPLICATION;
   

8. Możesz upewnić się, że używana rola ma uprawnienia do schematu, który replikujesz. W przeciwnym razie mogą wystąpić błędy, takie jak Permission denied for schema.

Uwaga

Zawsze dobrym rozwiązaniem jest oddzielenie użytkownika replikacji od zwykłego konta administratora.

Używanie replikacji logicznej i dekodowania logicznego

Użycie natywnej replikacji logicznej to najprostszy sposób replikowania danych z serwera elastycznego usługi Azure Database for PostgreSQL. Aby korzystać ze zmian, możesz użyć interfejsu SQL lub protokołu przesyłania strumieniowego. Interfejs SQL umożliwia również korzystanie ze zmian przy użyciu dekodowania logicznego.

Natywna replikacja logiczna

Replikacja logiczna używa terminów "wydawca" i "subskrybent".

• Wydawcą jest elastyczna baza danych serwera usługi Azure Database for PostgreSQL, z której wysyłasz dane.
• Subskrybentem jest elastyczna baza danych serwera usługi Azure Database for PostgreSQL, do której wysyłasz dane.

Oto przykładowy kod, którego można użyć do wypróbowania replikacji logicznej.

1. Połączenie do bazy danych wydawcy. Utwórz tabelę i dodaj dane.

   CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
   INSERT INTO basic VALUES (1, 'apple');
   INSERT INTO basic VALUES (2, 'banana');
   

2. Utwórz publikację dla tabeli.

   CREATE PUBLICATION pub FOR TABLE basic;
   

3. Połączenie do bazy danych subskrybentów. Utwórz tabelę z tym samym schematem co w wydawcy.

   CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);
   

4. Utwórz subskrypcję, która łączy się z utworzoną wcześniej publikacją.

   CREATE SUBSCRIPTION sub CONNECTION 'host=<server>.postgres.database.azure.com user=<rep_user> dbname=<dbname> password=<password>' PUBLICATION pub;
   

5. Teraz możesz wysłać zapytanie do tabeli na subskrybenta. Zobaczysz, że odebrano dane od wydawcy.

   SELECT * FROM basic;
   

   Możesz dodać więcej wierszy do tabeli wydawcy i wyświetlić zmiany dla subskrybenta.

   Jeśli nie widzisz danych, włącz uprawnienie azure_pg_admin logowania i sprawdź zawartość tabeli.

   ALTER ROLE azure_pg_admin login;
   

Odwiedź dokumentację bazy danych PostgreSQL, aby dowiedzieć się więcej na temat replikacji logicznej.

Używanie replikacji logicznej między bazami danych na tym samym serwerze

Jeśli chcesz skonfigurować replikację logiczną między różnymi bazami danych znajdującymi się w tym samym wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL, należy postępować zgodnie z konkretnymi wytycznymi, aby uniknąć ograniczeń implementacji, które są obecnie obecne. Od tej pory utworzenie subskrypcji łączącej się z tym samym klastrem bazy danych powiedzie się tylko wtedy, gdy miejsce replikacji nie zostanie utworzone w ramach tego samego polecenia; w przeciwnym razie wywołanie CREATE SUBSCRIPTION zawiesza się na LibPQWalReceiverReceive zdarzeniu oczekiwania. Dzieje się tak z powodu istniejącego ograniczenia w aucie Postgres, które może zostać usunięte w przyszłych wersjach.

Aby skutecznie skonfigurować replikację logiczną między bazami danych "source" i "target" na tym samym serwerze podczas obejścia tego ograniczenia, wykonaj kroki opisane poniżej:

Najpierw utwórz tabelę o nazwie "basic" z identycznym schematem zarówno w źródłowych, jak i docelowych bazach danych:

-- Run this on both source and target databases
CREATE TABLE basic (id INTEGER NOT NULL PRIMARY KEY, a TEXT);

Następnie w źródłowej bazie danych utwórz publikację dla tabeli i oddzielnie utwórz miejsce replikacji logicznej przy użyciu pg_create_logical_replication_slot funkcji, co pomaga zapobiec zawieszającemu się problemowi, który zwykle występuje, gdy miejsce jest tworzone w tym samym poleceniu co subskrypcja. Należy użyć wtyczki pgoutput :

-- Run this on the source database
CREATE PUBLICATION pub FOR TABLE basic;
SELECT pg_create_logical_replication_slot('myslot', 'pgoutput');

Następnie w docelowej bazie danych utwórz subskrypcję wcześniej utworzonej publikacji, upewniając się, że create_slot jest ona ustawiona tak, aby uniemożliwić false serwerowi elastycznemu usługi Azure Database for PostgreSQL utworzenie nowego miejsca i prawidłowe określenie nazwy miejsca utworzonego w poprzednim kroku. Przed uruchomieniem polecenia zastąp symbole zastępcze w parametry połączenia rzeczywistymi poświadczeniami bazy danych:

-- Run this on the target database
CREATE SUBSCRIPTION sub
   CONNECTION 'dbname=<source dbname> host=<server>.postgres.database.azure.com port=5432 user=<rep_user> password=<password>'
   PUBLICATION pub
   WITH (create_slot = false, slot_name='myslot');

Po skonfigurowaniu replikacji logicznej można ją teraz przetestować, wstawiając nowy rekord do tabeli "podstawowa" w źródłowej bazie danych, a następnie sprawdzając, czy jest replikowana do docelowej bazy danych:

-- Run this on the source database
INSERT INTO basic SELECT 3, 'mango';

-- Run this on the target database
TABLE basic;

Jeśli wszystko jest poprawnie skonfigurowane, należy zobaczyć nowy rekord ze źródłowej bazy danych w docelowej bazie danych, potwierdzając pomyślną konfigurację replikacji logicznej.

rozszerzenie pglogical

Oto przykład konfigurowania narzędzia pglogical na serwerze bazy danych dostawcy i subskrybentu. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją rozszerzenia pglogical. Upewnij się również, że zostały wykonane zadania wymagań wstępnych wymienionych powyżej.

1. Zainstaluj rozszerzenie pglogical w bazie danych zarówno na serwerach bazy danych dostawcy, jak i subskrybenta.

   \c myDB
   CREATE EXTENSION pglogical;
   

2. Jeśli użytkownik replikacji jest inny niż użytkownik administracyjny serwera (który utworzył serwer), upewnij się, że przyznasz członkostwu w roli azure_pg_admin użytkownikowi i przypisz atrybuty REPLIKACJA i LOGIN do użytkownika. Aby uzyskać szczegółowe informacje, zobacz dokumentację pglogical.

   GRANT azure_pg_admin to myUser;
   ALTER ROLE myUser REPLICATION LOGIN;
   

3. Na serwerze bazy danych dostawcy (źródło/wydawca) utwórz węzeł dostawcy.

   select pglogical.create_node( node_name := 'provider1',
   dsn := ' host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=myPassword');
   

4. Utwórz zestaw replikacji.

   select pglogical.create_replication_set('myreplicationset');
   

5. Dodaj wszystkie tabele w bazie danych do zestawu replikacji.

   SELECT pglogical.replication_set_add_all_tables('myreplicationset', '{public}'::text[]);
   

   Alternatywna metoda umożliwia również dodawanie tabel z określonego schematu (na przykład testUser) do domyślnego zestawu replikacji.

   SELECT pglogical.replication_set_add_all_tables('default', ARRAY['testUser']);
   

6. Na serwerze bazy danych subskrybentów utwórz węzeł subskrybenta.

   select pglogical.create_node( node_name := 'subscriber1',
   dsn := ' host=mySubscriberServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=myPasword' );
   

7. Utwórz subskrypcję, aby rozpocząć synchronizację i proces replikacji.

   select pglogical.create_subscription (
   subscription_name := 'subscription1',
   replication_sets := array['myreplicationset'],
   provider_dsn := 'host=myProviderServer.postgres.database.azure.com port=5432 dbname=myDB user=myUser password=myPassword');
   

8. Następnie możesz zweryfikować stan subskrypcji.

   SELECT subscription_name, status FROM pglogical.show_subscription_status();
   

Uwaga

Pglogical nie obsługuje obecnie automatycznej replikacji DDL. Początkowy schemat można skopiować ręcznie przy użyciu pg_dump --schema-only. Instrukcje DDL można wykonywać u dostawcy i subskrybenta jednocześnie przy użyciu funkcji pglogical.replicate_ddl_command. Pamiętaj o innych ograniczeniach rozszerzenia wymienionych tutaj.

Dekodowanie logiczne

Dekodowanie logiczne może być używane za pośrednictwem protokołu przesyłania strumieniowego lub interfejsu SQL.

Protokół przesyłania strumieniowego

Korzystanie ze zmian przy użyciu protokołu przesyłania strumieniowego jest często preferowane. Możesz utworzyć własnego klienta/łącznika lub użyć usługi innej firmy, takiej jak Debezium.

Zapoznaj się z dokumentacją pliku wal2json, aby zapoznać się z przykładem użycia protokołu przesyłania strumieniowego z pg_recvlogical.

Interfejs SQL

W poniższym przykładzie używamy interfejsu SQL z wtyczką wal2json.

1. Utwórz miejsce.

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Wydaj polecenia SQL. Na przykład:

   CREATE TABLE a_table (
      id varchar(40) NOT NULL,
      item varchar(40),
      PRIMARY KEY (id)
   );
   
   INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
   DELETE FROM a_table WHERE id='id1';
   

3. Korzystanie ze zmian.

   SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');
   

   Dane wyjściowe wyglądają następująco:

   {
         "change": [
         ]
   }
   {
         "change": [
                  {
                           "kind": "insert",
                           "schema": "public",
                           "table": "a_table",
                           "columnnames": ["id", "item"],
                           "columntypes": ["character varying(40)", "character varying(40)"],
                           "columnvalues": ["id1", "item1"]
                  }
         ]
   }
   {
         "change": [
                  {
                           "kind": "delete",
                           "schema": "public",
                           "table": "a_table",
                           "oldkeys": {
                                 "keynames": ["id"],
                                 "keytypes": ["character varying(40)"],
                                 "keyvalues": ["id1"]
                           }
                  }
         ]
   }
   

4. Po zakończeniu korzystania z niego upuść miejsce.

   SELECT pg_drop_replication_slot('test_slot');
   

Odwiedź dokumentację bazy danych PostgreSQL, aby dowiedzieć się więcej na temat dekodowania logicznego.

Monitorowanie

Należy monitorować dekodowanie logiczne. Każde nieużywane miejsce replikacji musi zostać usunięte. Miejsca są przechowywane w dziennikach bazy danych Postgres WAL i odpowiednich katalogach systemowych do czasu odczytania zmian. Jeśli subskrybent lub użytkownik ulegnie awarii lub jeśli jest nieprawidłowo skonfigurowany, nieskonsumowane dzienniki stosują się i wypełniają magazyn. Ponadto niekonsumowane dzienniki zwiększają ryzyko zawijania identyfikatora transakcji. Obie sytuacje mogą spowodować, że serwer stanie się niedostępny. W związku z tym miejsca replikacji logicznej muszą być używane w sposób ciągły. Jeśli miejsce replikacji logicznej nie jest już używane, usuń je natychmiast.

Kolumna "aktywna" w pg_replication_slots widoku wskazuje, czy użytkownik jest połączony z miejscem.

SELECT * FROM pg_replication_slots;

Ustaw alerty dotyczące maksymalnych używanych identyfikatorów transakcji i magazynu Używane metryki serwera elastycznego usługi Azure Database for PostgreSQL, aby otrzymywać powiadomienia o wzroście wartości poprzednich normalnych progów.

Ograniczenia

• Ograniczenia replikacji logicznej mają zastosowanie zgodnie z dokumentacją tutaj.

• Miejsca i tryb failover wysokiej dostępności — w przypadku korzystania z serwerów z obsługą wysokiej dostępności z elastycznym serwerem usługi Azure Database for PostgreSQL należy pamiętać, że miejsca replikacji logicznej nie są zachowywane podczas zdarzeń trybu failover. Aby zachować miejsca replikacji logicznej i zapewnić spójność danych po przejściu w tryb failover, zaleca się użycie rozszerzenia PG Miejsca trybu failover. Aby uzyskać więcej informacji na temat włączania tego rozszerzenia, zapoznaj się z dokumentacją.

Ważne

Należy usunąć miejsce replikacji logicznej na serwerze podstawowym, jeśli odpowiedni subskrybent już nie istnieje. W przeciwnym razie pliki WAL gromadzą się w magazynie podstawowym, wypełniając magazyn. Załóżmy, że próg magazynu przekracza określony próg, a miejsce replikacji logicznej nie jest używane (ze względu na niedostępnego subskrybenta). W takim przypadku wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL automatycznie odrzuca to nieużywane miejsce replikacji logicznej. Ta akcja zwalnia skumulowane pliki WAL i pozwala uniknąć niedostępności serwera z powodu zapełniania magazynu.

Powiązana zawartość

• opcje sieciowe
• Rozszerzenia
• wysoka dostępność