Отказоустойчивость логической репликации

примечание

Эта страница переведена при помощи нейросети GigaChat.

Чтобы позволить узлам-подписчикам продолжать реплицировать данные от узла-издателя даже при его отказе, должен существовать физический резервный узел, соответствующий узлу-издателю. Логические слоты на основном сервере, соответствующие подпискам, могут быть синхронизированы с резервным сервером путем указания failover = true при создании подписок. Подробности см. в разделе «Синхронизация слотов репликации». Включение параметра failover обеспечивает бесшовное переключение этих подписок после повышения статуса резервного сервера. Они смогут продолжить подписку на публикации на новом первичном сервере.

Поскольку логика синхронизации слотов копирует асинхронно, необходимо убедиться, что слоты репликации были синхронизированы с резервным сервером до того, как произойдет отказ. Чтобы обеспечить успешную процедуру отказа, резервный сервер должен опережать подписчика. Это можно сделать, настроив параметр synchronized_standby_slots.

Для подтверждения готовности резервного сервера к процедуре отказа выполните следующие шаги для проверки того, что все необходимые логические слоты репликации были синхронизированы с резервным сервером:

На узле-подписчике используйте следующий SQL-запрос, чтобы определить, какие слоты репликации должны быть синхронизированы с резервным сервером, который планируем повысить. Этот запрос вернет соответствующие слоты репликации, связанные с подписками, включающими возможность перехода на другой ресурс.
```
test_sub=# SELECT
               array_agg(quote_literal(s.subslotname)) AS slots
           FROM  pg_subscription s
           WHERE s.subfailover AND
                 s.subslotname IS NOT NULL;
 slots
-------
 {'sub1','sub2','sub3'}
(1 row)
```
На узле-подписчике используйте следующий SQL-запрос, чтобы определить, какие слоты синхронизации таблиц должны быть синхронизированы с резервным сервером, который планируем повысить. Запрос нужно выполнить на каждой базе данных, содержащей подписки с возможностью перехода на другой ресурс. Обратите внимание, что слот синхронизации таблицы следует синхронизировать с резервным сервером только в том случае, если копия таблицы завершена (см. раздел «pg_subscription_rel»). Нет необходимости обеспечивать синхронизацию слотов синхронизации таблиц в других сценариях, так как они будут либо удалены, либо повторно созданы на новом первичном сервере в таких случаях.
```
test_sub=# SELECT
               array_agg(quote_literal(slot_name)) AS slots
           FROM
           (
               SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_identifier) AS slot_name
               FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscription s
               WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover
           );
 slots
-------
 {'pg_16394_sync_16385_7394666715149055164'}
(1 row)
```

Убедитесь, что идентифицированные выше логические слоты репликации существуют на резервном сервере и готовы к переходу на другой ресурс.

test_standby=# SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS failover_ready
               FROM pg_replication_slots
               WHERE slot_name IN
                   ('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164');
  slot_name                                 | failover_ready
--------------------------------------------+----------------
  sub1                                      | t
  sub2                                      | t
  sub3                                      | t
  pg_16394_sync_16385_7394666715149055164   | t
(4 rows)

Если все указанные слоты присутствуют на резервном сервере и результат (failover_ready) вышеуказанного запроса SQL равен true, существующие подписки теперь могут продолжить подписку на публикации на новом первичном сервере.