Dekodowanie logiczne

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer

Ważne

Usługa Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do usługi Azure Database for PostgreSQL — serwer elastyczny. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for PostgreSQL — serwer elastyczny, zobacz Co się dzieje z usługą Azure Database for PostgreSQL — pojedynczy serwer?.

Dekodowanie logiczne w usłudze PostgreSQL umożliwia przesyłanie strumieniowe zmian danych do użytkowników zewnętrznych. Dekodowanie logiczne jest popularne w scenariuszach przesyłania strumieniowego zdarzeń i przechwytywania zmian danych.

Dekodowanie logiczne używa wtyczki wyjściowej do konwertowania dziennika zapisu z wyprzedzeniem (WAL) bazy danych Postgres na czytelny format. Usługa Azure Database for PostgreSQL udostępnia wtyczki wyjściowe wal2json, test_decoding i pgoutput. Narzędzie pgoutput jest udostępniane przez program PostgreSQL z bazy danych PostgreSQL w wersji 10 i nowszej.

Aby zapoznać się z omówieniem sposobu działania dekodowania logicznego bazy danych Postgres, odwiedź nasz blog.

Uwaga

Replikacja logiczna korzystająca z publikacji/subskrypcji postgreSQL nie jest obsługiwana w usłudze Azure Database for PostgreSQL — pojedynczy serwer.

Konfigurowanie serwera

Dekodowanie logiczne i repliki do odczytu zależą od dziennika z wyprzedzeniem zapisu Postgres (WAL) w celu uzyskania informacji. Te dwie funkcje wymagają różnych poziomów rejestrowania z bazy danych Postgres. Dekodowanie logiczne wymaga wyższego poziomu rejestrowania niż repliki do odczytu.

Aby skonfigurować odpowiedni poziom rejestrowania, użyj parametru obsługi replikacji platformy Azure. Obsługa replikacji platformy Azure ma trzy opcje ustawień:

  • Wyłączone — umieszcza najmniej informacji w pliku WAL. To ustawienie nie jest dostępne na większości serwerów usługi Azure Database for PostgreSQL.
  • Replika — więcej informacji niż wyłączone. Jest to minimalny poziom rejestrowania potrzebny do pracy replik do odczytu. To ustawienie jest ustawieniem domyślnym dla większości serwerów.
  • Logiczne — bardziej pełne niż replika. Jest to minimalny poziom rejestrowania dla dekodowania logicznego do pracy. Repliki do odczytu działają również w tym ustawieniu.

Korzystanie z interfejsu wiersza polecenia platformy Azure

  1. Ustaw azure.replication_support na logical.

    az postgres server configuration set --resource-group mygroup --server-name myserver --name azure.replication_support --value logical

  2. Uruchom ponownie serwer, aby zastosować zmianę.

    az postgres server restart --resource-group mygroup --name myserver

  3. Jeśli używasz programu Postgres 9.5 lub 9.6 i używasz dostępu do sieci publicznej, dodaj regułę zapory, aby uwzględnić publiczny adres IP klienta, z którego będzie uruchamiana replikacja logiczna. Nazwa reguły zapory musi zawierać _replrule. Na przykład test_replrule. Aby utworzyć nową regułę zapory na serwerze, uruchom polecenie az postgres server firewall-rule create .

Przy użyciu witryny Azure Portal

  1. Ustaw obsługę replikacji platformy Azure na wartość logiczną. Wybierz pozycję Zapisz.

    Azure Database for PostgreSQL — replikacja — obsługa replikacji platformy Azure

  2. Uruchom ponownie serwer, aby zastosować zmianę, wybierając pozycję Tak.

    Azure Database for PostgreSQL — replikacja — potwierdzanie ponownego uruchomienia

  3. Jeśli używasz programu Postgres 9.5 lub 9.6 i używasz dostępu do sieci publicznej, dodaj regułę zapory, aby uwzględnić publiczny adres IP klienta, z którego będzie uruchamiana replikacja logiczna. Nazwa reguły zapory musi zawierać _replrule. Na przykład test_replrule. Następnie wybierz opcję Zapisz.

    Azure Database for PostgreSQL — replikacja — dodawanie reguły zapory

Uruchamianie dekodowania logicznego

Dekodowanie logiczne może być używane za pośrednictwem protokołu przesyłania strumieniowego lub interfejsu SQL. Obie metody używają miejsc replikacji. Miejsce reprezentuje strumień zmian z pojedynczej bazy danych.

Użycie miejsca replikacji wymaga uprawnień replikacji bazy danych Postgres. Obecnie uprawnienie replikacji jest dostępne tylko dla administratora serwera.

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ć narzędzia takiego 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 będą wyglądać 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');

Miejsca monitorowania

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 momentu odczytania zmian przez użytkownika. Jeśli użytkownik ulegnie awarii lub nie został prawidłowo skonfigurowany, nieskonsumowane dzienniki będą stosować i wypełniać 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 ważne jest, aby miejsca replikacji logicznej są stale używane. Jeśli miejsce replikacji logicznej nie jest już używane, usuń je natychmiast.

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

SELECT * FROM pg_replication_slots;

Ustaw alerty dotyczące używanego magazynu i maksymalne opóźnienie w metrykach replik, aby otrzymywać powiadomienia o wzroście wartości poprzednich progów normalnych.

Ważne

Należy usunąć nieużywane miejsca replikacji. Nie można tego zrobić, może prowadzić do niedostępności serwera.

Jak usunąć miejsce

Jeśli nie korzystasz aktywnie z miejsca replikacji, usuń je.

Aby usunąć miejsce replikacji o nazwie test_slot przy użyciu języka SQL:

SELECT pg_drop_replication_slot('test_slot');

Ważne

Jeśli przestaniesz używać dekodowania logicznego, zmień azure.replication_support z powrotem na replica lub off. Szczegóły wal przechowywane przez logical są bardziej pełne i powinny być wyłączone, gdy dekodowanie logiczne nie jest używane.

Następne kroki

  • Odwiedź dokumentację bazy danych Postgres, aby dowiedzieć się więcej na temat dekodowania logicznego.
  • Skontaktuj się z naszym zespołem, jeśli masz pytania dotyczące dekodowania logicznego.
  • Dowiedz się więcej o replikach do odczytu.