Логическое декодирование

  • Статья

Область применения: отдельный сервер Базы данных Azure для PostgreSQL

Внимание

База данных Azure для PostgreSQL — одиночный сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для PostgreSQL — гибкий сервер см. в статье "Что происходит с одним сервером База данных Azure для PostgreSQL?".

Логическое декодирование в PostgreSQL позволяет передавать поток сведений об изменениях данных внешним потребителям. Логическое декодирование часто используется в сценариях потоковой передачи событий и отслеживания измененных данных.

Для логического декодирования используется подключаемый модуль вывода, который преобразует данные из формата упреждающей журнализации (WAL) Postgres в доступный для чтения формат. База данных Azure для PostgreSQL предоставляет подключаемые модули вывода wal2json, test_decoding и pgoutput. Модуль pgoutput доступен в PostgreSQL начиная с версии 10.

Общие сведения о том, как работает логическое декодирование Postgres, см. в нашем блоге.

Примечание.

Логическая репликация с использованием публикации или подписки PostgreSQL не поддерживается в службе "Одиночный сервер Базы данных Azure для PostgreSQL".

Настройка сервера

Логическое декодирование и реплики чтения получают данные от упреждающей журнализации (WAL) Postgres. Для этих двух функций требуются разные уровни ведения журнала от Postgres. Логическому декодированию нужен более высокий уровень ведения журнала, чем репликам чтения.

Чтобы правильно настроить уровень ведения журнала, используйте параметр поддержки репликации Azure. Параметр поддержки репликации Azure имеет три варианта значений:

  • Выкл. — в WAL записывается минимум информации. Этот вариант недоступен на большинстве серверов Базы данных Azure для PostgreSQL.
  • Реплика — более подробное протоколирование, чем в режиме Выкл. Это минимальный уровень ведения журнала, необходимый для работы реплик чтения. Этот вариант используется по умолчанию на большинстве серверов.
  • Логический — более подробное протоколирование, чем в режиме Реплика. Это минимальный уровень ведения журнала для работы логического декодирования. Реплики чтения тоже работают с этим вариантом.

Использование Azure CLI

  1. Задайте для параметра azure.replication_support значение logical.

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

  2. Перезагрузите сервер, чтобы это изменение вступило в силу.

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

  3. Если вы используете Postgres версии 9.5 или 9.6 и доступ к общедоступной сети, добавьте разрешающее правило брандмауэра с общедоступным IP-адресом клиента, с которого будет выполняться логическая репликация. Имя этого правила брандмауэра должно включать строку _replrule. Например, test_replrule. Чтобы создать правило брандмауэра на сервере, выполните команду az postgres server firewall-rule create.

Используя портал Azure

  1. Задайте для параметра поддержки репликации Azure значение logical (логическое). Выберите Сохранить.

    База данных Azure для PostgreSQL — репликация — поддержка репликации Azure

  2. Перезапустите сервер, чтобы применить изменение, выбрав Да.

    База данных Azure для PostgreSQL —репликация — подтверждение перезапуска

  3. Если вы используете Postgres версии 9.5 или 9.6 и доступ к общедоступной сети, добавьте разрешающее правило брандмауэра с общедоступным IP-адресом клиента, с которого будет выполняться логическая репликация. Имя этого правила брандмауэра должно включать строку _replrule. Например, test_replrule. Затем выберите Сохранить.

    База данных Azure для PostgreSQL — репликация — добавление правила брандмауэра

Запуск логического декодирования

Логическое декодирование можно использовать через протокол потоковой передачи или интерфейс SQL. Оба метода используют слоты репликации. Такой слот представляет поток изменений из одной базы данных.

Для использования слота репликации требуются права репликации Postgres. В настоящее время привилегия репликации доступна только для пользователя с ролью администратора сервера.

Протокол потоковой передачи

Зачастую предпочтительным вариантом обработки изменений является использование протокола потоковой передачи. Вы можете создать собственный объект-получатель или соединитель либо применить другие средства, например Debezium.

Ознакомьтесь с документацией по wal2json, чтобы увидеть пример использования протокола потоковой передачи с pg_recvlogical.

Интерфейс SQL

В приведенном ниже примере используется интерфейс SQL с подключаемым модулем wal2json.

  1. Создайте слот.

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

  2. Выполните команды SQL. Например:

    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. Получите изменения.

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

    Выходные данные будут выглядеть следующим образом:

    {
      "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. Удалите слот, если его больше не нужно использовать.

    SELECT pg_drop_replication_slot('test_slot');

Слоты мониторинга

Для логического декодирования нужно выполнять мониторинг. Все неиспользуемые слоты репликации необходимо удалять. Слоты сохраняют журналы WAL Postgres и соответствующие системные каталоги, пока изменения не будут считаны потребителем. В случае сбоя или неправильной настройки потребителя неиспользованные журналы будут накапливаться и заполнять хранилище. Кроме того, неиспользованные журналы увеличивают риск циклического возврата идентификатора транзакции. Обе эти ситуации могут привести к недоступности сервера. Поэтому важно постоянно обрабатывать слоты логической репликации. Если слот логической репликации больше не используется, немедленно удалите его.

Столбец active в представлении pg_replication_slots будет указывать на наличие потребителей, подключенных к слоту.

SELECT * FROM pg_replication_slots;

Настройте оповещения по метрикам Используемое хранилище и Максимальная задержка между репликами, чтобы своевременно заметить превышение обычных пороговых значений.

Внимание

Необходимо удалять все неиспользуемые слоты репликации. Без этого сервер может стать недоступным.

Удаление слота

Если вы не используете слот репликации, удалите его.

Для удаления слота репликации с именем test_slot с помощью SQL сделайте следующее:

SELECT pg_drop_replication_slot('test_slot');

Внимание

Если вы решите отказаться от логического декодирования, задайте для azure.replication_support прежнее значение (replica или off). На уровне logical WAL сохраняет более подробные сведения, и его лучше отключить, если логическое декодирование не используется.

Следующие шаги