Резервный кластер (Standby cluster)

примечание

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

Patroni также поддерживает запуск каскадной репликации в удаленный дата-центр (регион) с использованием функции, называемой «резервный кластер» (standby cluster). Этот тип кластеров имеет:

«лидер standby» (standby leader), который ведет себя практически как обычный лидер кластера, за исключением того, что он реплицируется с удаленного узла. -каскадные реплики, которые реплицируются с лидера standby.

Лидер standby удерживает и обновляет блокировку лидера в DCS. Если блокировка лидера истекает, каскадные реплики выполнят выборы для выбора другого лидера из standby.

Между резервным кластером и первичным кластером, с которого он реплицируется, нет дальнейших взаимосвязей; в частности, они не должны использовать одно и то же пространство имен (scope) DCS, если они используют один и тот же DCS. Они не знают ничего друг о друге, кроме информации о репликации. Кроме того, резервный кластер не отображается в выводе команд patronictl list или patronictl topology на первичном кластере.

Ради гибкости можно указать методы создания реплики и восстановления записей WAL, когда кластер находится в «режиме standby», предоставив ключ создания реплик в разделе standby_cluster. Это отличается от создания реплик, когда кластер отсоединен и функционирует как нормальный кластер, что контролируется параметром create_replica_methods в разделе postgresql. Оба набора методов создания реплик — «standby» и «нормальные» — ссылаются на ключи в разделе postgresql.

Для настройки такого кластера необходимо указать раздел standby_cluster в конфигурации Patroni:

bootstrap:
    dcs:
        standby_cluster:
            host: 1.2.3.4
            port: 5432
            primary_slot_name: patroni
            create_replica_methods:
            - basebackup

Обратите внимание: эти опции будут применены только один раз во время бутстрапа кластера, и единственный способ изменить их впоследствии — через DCS.

Patroni ожидает найти postgresql.conf или postgresql.conf.backup в каталоге PGDATA удаленного первичного узла и не запустится, если не найдет его после выполнения basebackup. Если удаленный первичный узел хранит свой postgresql.conf в другом месте, необходимо скопировать его в каталог PGDATA.

Если используются слоты репликации в резервном кластере, также необходимо создать соответствующий слот репликации на первичном кластере. Это не будет сделано автоматически реализацией резервного кластера. Можно использовать функцию постоянных слотов репликации Patroni на первичном кластере для поддержания слота репликации с тем же именем, что и primary_slot_name, или его значением по умолчанию, если primary_slot_name не предоставлен.

В случае, если удаленный сайт не предоставляет единую конечную точку, которая подключается к первичному узлу, можно перечислить все хосты исходного кластера в разделе standby_cluster.host. Когда standby_cluster.host содержит несколько хостов, разделенных запятыми, Patroni будет:

добавлять target_session_attrs=read-write в primary_conninfo на узле-лидере standby.
использовать target_session_attrs=read-write при попытке определить, нужно ли запускать pg_rewind, или при выполнении pg_rewind на всех узлах резервного кластера.
Важно отметить: для успешной работы pg_rewind кластер должен быть инициализирован с контрольными суммами страниц данных (опция --data-checksums для initdb) и/или wal_log_hints должен быть установлен в on. В противном случае pg_rewind не будет работать корректно.

Также существует возможность реплицировать резервный кластер с другого резервного кластера или с участника-standby первичного кластера: для этого необходимо определить один хост в разделе standby_cluster.host. Однако следует учитывать, что в этом случае pg_rewind не сможет выполниться в резервном кластере.