Создание реплик и инициализация
Эта страница переведена при помощи нейросети GigaChat.
Patroni позволяет настраивать создание новой реплики. Он также поддерживает определение того, что происходит при начальной загрузке нового пустого кластера. Различие между ними хорошо определено: Patroni создает реплики только в том случае, если ключ initialize присутствует в DCS для кластера. Если нет ключа initialize – Patroni вызывает начальную загрузку исключительно на первом узле, который принимает блокировку ключа инициализации.
Инициализация
PostgreSQL предоставляет команду initdb для инициализации нового кластера, и Patroni вызывает ее по умолчанию. В некоторых случаях, особенно когда создается новый кластер в виде копии существующего, необходимо заменить встроенный метод пользовательскими действиями. Patroni поддерживает выполнение сценариев, определенных пользователем, для начальной загрузки новых кластеров, предоставляя им некоторые необходимые аргументы, например имя кластера и путь к каталогу данных. Это настроено в разделе bootstrap конфигурации Patroni. Например:
bootstrap:
method: <custom_bootstrap_method_name>
<custom_bootstrap_method_name>:
command: <path_to_custom_bootstrap_script> [param1 [, ...]]
keep_existing_recovery_conf: False
no_params: False
recovery_conf:
recovery_target_action: promote
recovery_target_timeline: latest
restore_command: <method_specific_restore_command>
Каждый метод начальной загрузки должен определять хотя бы один name и один command. Специальный метод initdb доступен для запуска поведения по умолчанию, в этом случае параметр method может быть полностью опущен. Путь command может быть указан в виде абсолютного пути, либо в виде пути относительно места расположения команды patroni. Помимо фиксированных параметров, определенных в файлах конфигурации, Patroni предоставляет два специфичных для кластера параметра:
--scope– имя кластера, который будет загружен;--datadir– путь к каталогу данных загружаемого экземпляра кластера.
Передача этих двух дополнительных флагов может быть отключена путем установки специального параметра no_params на True.
Если сценарий начальной загрузки возвращает 0, Patroni пытается настроить и запустить экземпляр PostgreSQL, созданный им. Если какой-либо из промежуточных шагов завершится сбоем или сценарий вернет ненулевое значение, Patroni предполагает, что начальная загрузка не удалась, запускает очистку и освобождает блокировку инициализации, чтобы предоставить другому узлу возможность выполнить начальную загрузку.
Если блок recovery_conf определен в том же разделе, что и метод начальной загрузки, Patroni сгенерирует recovery.conf перед запуском нового загруженного экземпляра (или установите параметры восстановления в конфигурации Postgres, если выполняется PostgreSQL & gt; = 12). Обычно такая конфигурация восстановления должна содержать по крайней мере один из параметров recovery_target_*, вместе с установленным значением recovery_target_timeline на promote.
Если keep_existing_recovery_conf определен и установлен на True, Patroni не удаляет существующий файл recovery.conf, если он существует (PostgreSQL <= 11). Аналогично, в этом случае Patroni не удаляет существующие файлы recovery.signal или standby.signal, если они существуют, и не переопределяет настроенные параметры восстановления (PostgreSQL >= 12). Это полезно при выполнении начальной загрузки из резервной копии с помощью таких инструментов, как pgBackRest, которые генерируют соответствующую конфигурацию восстановления.
Кроме того, любые дополнительные пары ключ/значение, указанные в конфигурации метода пользовательской начальной загрузки, будут переданы в качестве аргументов к command в формате --name=value. Например:
bootstrap:
method: <custom_bootstrap_method_name>
<custom_bootstrap_method_name>:
command: <path_to_custom_bootstrap_script>
arg1: value1
arg2: value2
Делает сконфигурированную команду command вызываемой дополнительно с аргументами командной строки --arg1=value1 --arg2=value2.
Примечание
Методы начальной загрузки не объединяются и не возвращаются к методу по умолчанию в случае сбоя основного метода
Создание реплик
Patroni использует проверенные и доказанные pg_basebackup для создания новых реплик. Один из недостатков является то, что он требует работающего узла-лидера. Другой недостаток – отсутствие сжатия данных резервного копирования на «лету» для резервных данных и отсутствие встроенной очистки устаревших файлов резервных копий. Некоторые предпочитают другие решения для резервного копирования, такие как WAL-E, pgBackRest, Barman и другие, или просто создают свои собственные сценарии. Чтобы удовлетворить все эти варианты использования, Patroni поддерживает выполнение пользовательских сценариев для клонирования новой реплики. Они настроены в блоке конфигурации postgresql:
postgresql:
create_replica_methods:
- <method name>
<method name>:
command: <command name>
keep_data: True
no_params: True
no_leader: 1
пример wal_e:
postgresql:
create_replica_methods:
- wal_e
- basebackup
wal_e:
command: patroni_wale_restore
no_leader: 1
envdir: {{WALE_ENV_DIR}}
use_iam: 1
basebackup:
max-rate: '100M'
пример pgbackrest:
postgresql:
create_replica_methods:
- pgbackrest
- basebackup
pgbackrest:
command: /usr/bin/pgbackrest --stanza=<scope> --delta restore
keep_data: True
no_params: True
basebackup:
max-rate: '100M'
create_replica_methods определяет доступные методы создания реплик и порядок их выполнения. Patroni остановится на первом методе, который вернет 0. Каждый метод должен определять отдельный раздел в файле конфигурации, перечисляя команду для выполнения и любые специальные параметры, которые должны быть переданы этой команде. Все параметры будут передаваться в формате --name=value. Помимо параметров, определяемых пользователем, Patroni предоставляет несколько специфичных для кластера:
[\--scope]{.kbd}– кластер, которому принадлежит эта реплика;[\--datadir]{.kbd}– путь к каталогу данных реплики;[\--role]{.kbd}– всегда «реплика»;[\--connstring]{.kbd}– строка соединения для подключения к участнику кластера, с которого будет выполняться клонирование (основная или другая реплика). Пользователь в строке подключения может выполнять команды SQL и протокола репликации.
Специальный параметр no_leader , если он определен, позволяет Patroni вызывать метод создания реплики, даже если нет запущенного лидера или реплик. В этом случае в строке соединения будет передана пустая строка. Это полезно для восстановления ранее запущенного кластер из бинарной резервной копии.
Специальный параметр keep_data, если он определен, указывает Patroni не очищать папку PGDATA перед вызовом restore.
Специальный параметр no_params, если он определен, ограничивает передачу параметров в пользовательскую команду.
Метод basebackup – это особый случай: он будет использоваться, если create_replica_methods пуст, хотя его можно явно перечислить среди методов create_replica_methods. Этот метод инициализирует новую реплику с помощью pg_basebackup, базовая резервная копия берется из лидера, если только не существует реплик с меткой clonefrom, в этом случае одна из таких реплик будет использована в качестве источника для pg_basebackup. Метод работает без какой-либо конфигурации; однако можно указать раздел конфигурации basebackup. Здесь действуют те же правила, что и при конфигурировании других методов, а именно, следует указывать только длинные (с -) параметры.
Не все параметры имеют смысл. Если переопределить соединение или указать опцию создания резервных копий базы в tar- или сжатом виде, patroni не сможет создать из них реплику. Никакой проверки имен или значений параметров, передаваемых в секцию basebackup, не выполняется. Также обратите внимание, что в случае использования символьных ссылок для каталога WAL, пользователю придется указать правильный путь --waldir в качестве опции, чтобы после сборки реплики или повторной инициализации символьная ссылка сохранилась. Эта опция поддерживается только с версии 10.
Параметры basebackup можно задавать в виде карты (пары ключ-значение) или списка элементов, где каждый элемент может быть как парой ключ-значение, так и одним ключом (для опций, не принимающих значений, например, --verbose). Рассмотрим эти два примера:
postgresql:
basebackup:
max-rate: '100M'
checkpoint: 'fast'
и
postgresql:
basebackup:
- verbose
- max-rate: '100M'
- waldir: /pg-wal-mount/external-waldir
Если все методы создания реплики окажутся неудачными, Patroni повторит попытку создания всех методов по порядку во время следующего цикла событий.
Резервный кластер
Другой доступный вариант – запустить «резервный кластер», состоящий только из резервных узлов, реплицирующихся с какого-то удаленного узла. Этот тип кластеров имеет:
- «резервный лидер», который ведет себя практически так же, как и обычный лидер кластера, за исключением того, что он реплицируется с удаленного узла;
- каскадные реплики, которые реплицируются с резервного лидера.
Резервный лидер удерживает и обновляет блокировку лидера в DCS. Если срок действия блокировки лидера истекает, каскадные реплики выполняют выборы, чтобы выбрать другого лидера из резервных.
Между резервным кластером и основным кластером, с которого он реплицируется, нет никаких дополнительных отношений, в частности, они не должны использовать одну и ту же область действия DCS, если они используют один и тот же DCS. Кроме информации о репликации, они больше ничего не знают друг о друге. Кроме того, резервный кластер не отображается patronictl list или patronictl topology на первичном кластере.
Для обеспечения гибкости можно указать методы создания реплик и восстановительных WAL-записей, когда кластер находится в «режиме ожидания», указав ключ create_replica_methods в секции standby_cluster. Это отличается от создания реплик, когда кластер отсоединен и функционирует как обычный кластер, что контролируется ключом create_replica_methods в секции postgresql. И «standby», и «normal» create_replica_methods ссылаются на ключи в секции postgresql.
Чтобы настроить такой кластер, необходимо указать секцию standby_cluster в конфигурации Patroni:
bootstrap:
dcs:
standby_cluster:
host: {IP-Address}
port: 5432
primary_slot_name: patroni
create_replica_methods:
- basebackup
Обратите внимание, что эти опции будут применены только один раз во время загрузки кластера, и единственный способ изменить их впоследствии – через DCS.
Patroni ожидает найти postgresql.conf или postgresql.conf.backup в PGDATA удаленного основного сервера и не будет запускаться, если не найдет его после базового резервного копирования. Если удаленный основной сервер хранит свой postgresql.conf где-то еще, то необходимо скопировать его в PGDATA.
Если использовать слоты репликации на резервном кластере, необходимо создать соответствующий слот репликации на основном кластере. Это не будет сделано автоматически при реализации резервного кластера. Можно использовать функцию постоянных слотов репликации Patroni на первичном кластере, чтобы поддерживать слот репликации с тем же именем, что и primary_slot_name, или его значение по умолчанию, если primary_slot_name не указано.