Резервный кластер (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:

`yaml 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 не сможет выполниться в резервном кластере.

warning

Имена участников (поле name в конфигурации Patroni каждого узла) должны быть уникальными в основном кластере и всех резервных кластерах, подключенных к нему.

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

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