Создание реплик и инициализация

примечание

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

Patroni позволяет настраивать создание новой реплики. Он также поддерживает определение того, что происходит при бутстрапе нового пустого кластера. Различие между двумя хорошо определено: Patroni создает реплики только если ключ initialize присутствует в DCS для кластера. Если ключа initialize нет — Patroni вызывает бутстрап исключительно на первом узле, который захватывает блокировку ключа initialize.

Инициализация

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

Если в том же разделе, что и пользовательский метод бутстрапа, определен блок recovery_conf, Patroni сгенерирует recovery.conf перед запуском нового бутстрапнутого экземпляра (или установит настройки восстановления в конфигурации Postgres, если используется PostgreSQL >= 12). Обычно такая конфигурация восстановления должна содержать как минимум один из параметров recovery_target_* вместе с recovery_target_action, установленным в 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 из резервной копии Barman с конфигурацией такого вида:

bootstrap:
    method: barman
    barman:
        keep_existing_recovery_conf: true
        command: patroni_barman --api-url https://barman-host:7480 recover
        barman-server: my_server
        ssh-command: ssh postgres@patroni-host

примечание

patroni_barman recover требует, чтобы были настроены как Barman, так и pg-backup-api на хосте Barman, чтобы он мог выполнять удаленный barman recover через API резервного копирования. Приведенный выше пример использует подмножество доступных параметров. Дополнительную информацию можно получить, запустив patroni_barman recover --help.

Создание реплик

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, если он определен, ограничивает передачу параметров в пользовательскую команду.

Пример Barman

postgresql:
    create_replica_methods:
        - barman
        - basebackup
    barman:
        command: patroni_barman --api-url https://barman-host:7480 recover
        barman-server: my_server
        ssh-command: ssh postgres@patroni-host
    basebackup:
        max-rate: '100M'

примечание

create_replica_methods определяет доступные методы создания реплик и порядок их выполнения. Patroni остановится на первом, который вернет 0. Каждый метод должен определять отдельный раздел в файле конфигурации, перечисляя команду для выполнения и любые пользовательские параметры, которые должны быть переданы этой команде. Все параметры будут переданы в формате --name=value. Помимо пользовательских параметров, Patroni передает несколько специфичных для кластера:

Параметр	Описание
`--scope`	К какому кластеру принадлежит эта реплика
`--datadir`	Путь к каталогу данных реплики
`--role`	Всегда 'replica'
`--connstring`	Строка подключения для подключения к участнику кластера, из которого нужно клонировать (первичный узел или другая реплика). Пользователь в строке подключения может выполнять команды SQL и протокола репликации.

Специальный параметр no_leader, если определен, позволяет Patroni вызывать метод создания реплики даже если нет работающего лидера или реплик. В этом случае в строке подключения будет передана пустая строка. Это полезно для восстановления ранее работавшего кластера из бинарной резервной копии.

Специальный параметр keep_data, если определен, инструктирует Patroni не очищать папку PGDATA перед вызовом восстановления.

Специальный параметр no_params, если определен, запрещает передачу параметров в пользовательскую команду.

Метод basebackup — это особый случай: он будет использован, если create_replica_methods пуст, хотя его можно явно перечислить среди методов create_replica_methods. Этот метод инициализирует новую реплику с помощью pg_basebackup; базовая резервная копия берется с лидера, если только нет реплик с тегом clonefrom, в этом случае одна из таких реплик будет использована как источник для pg_basebackup. Он работает без какой-либо конфигурации; однако можно указать раздел конфигурации basebackup. Применяются те же правила, что и для конфигурации других методов, а именно, следует указывать только длинные опции (с --). Не все параметры имеют смысл: если будет переопределена строка подключения или предоставлена опция для создания tar-архивированных или сжатых базовых резервных копий, Patroni не сможет создать из этого реплику. Валидация имен или значений параметров, переданных в раздел basebackup, не выполняется. Также обратите внимание: в случае использования символических ссылок для папки WAL пользователь должен указать правильный путь --waldir как опцию, чтобы после создания реплики или повторной инициализации символическая ссылка сохранилась. Эта опция поддерживается только начиная с v10.

Параметры basebackup можно указать либо как отображение (пары ключ-значение), либо как список элементов, где каждый элемент может быть либо парой ключ-значение, либо одиночным ключом (для опций, не принимающих значений, например, --verbose). Рассмотрим эти 2 примера:

postgresql:
    basebackup:
        max-rate: '100M'
        checkpoint: 'fast'

postgresql:
    basebackup:
        - verbose
        - max-rate: '100M'
        - waldir: /pg-wal-mount/external-waldir

Если все методы создания реплик завершаются ошибкой, Patroni попытается снова все методы по порядку в следующем цикле цикла событий.

Инициализация​

Создание реплик​

Пример wal_e​

Пример pgbackrest​

Пример Barman​

Инициализация

Создание реплик

Пример wal_e

Пример pgbackrest

Пример Barman