29.3. Переключение на резервную копию логической репликации#

29.3. Переключение на резервную копию логической репликации

29.3. Переключение на резервную копию логической репликации #

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

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

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

  1. На узле подписчика используйте следующий 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)
    
  2. На узле подписчика используйте следующий SQL, чтобы определить, какие слоты синхронизации таблиц должны быть синхронизированы с резервным сервером, который мы планируем повысить. Этот запрос необходимо выполнить в каждой базе данных, которая включает подписки с поддержкой отказа. Обратите внимание, что слот синхронизации таблицы должен быть синхронизирован с резервным сервером только в том случае, если копирование таблицы завершено (см. Раздел 51.55). Нам не нужно обеспечивать синхронизацию слотов синхронизации таблиц в других сценариях, так как они будут либо удалены, либо воссозданы на новом основном сервере в этих случаях.

    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)
    
  3. Проверьте, что логические слоты репликации, указанные выше, существуют на резервном сервере и готовы к переключению.

    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-запроса истинный, то существующие подписки могут продолжать подписываться на публикации, которые теперь находятся на новом первичном сервере.