Динамические настройки конфигурации

примечание

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

Динамическая конфигурация хранится в DCS (распределенном хранилище конфигурации) и применяется на всех узлах кластера.

Чтобы изменить динамическую конфигурацию, можно использовать либо инструмент patronictl edit-config, либо REST API Patroni:

loop_wait – количество секунд, в течение которых цикл будет спать. Значение по умолчанию: 10, минимальное возможное значение: 1;
ttl – время жизни для получения блокировки лидера (в секундах). Представьте это как продолжительность времени до начала процесса автоматического восстановления после сбоя. Значение по умолчанию: 30, минимальное возможное значение: 20;
retry_timeout – тайм-аут для повторных попыток операций DCS и PostgreSQL (в секундах). Проблемы с DCS или сетью короче этого значения не приведут к понижению уровня лидера Patroni. Значение по умолчанию: 10, минимальное возможное значение: 3.

примечание

При изменении значений loop_wait, retry_timeout или ttl необходимо следовать правилу:

loop_wait + 2 * retry_timeout <= ttl

maximum_lag_on_failover – максимальное количество байт, на которое может отставать последователь от лидера для участия в выборах лидера.
maximum_lag_on_syncnode – максимальное количество байт, на которое синхронный последователь может отставать перед тем, как он будет считаться нездоровым кандидатом и заменен здоровым асинхронным последователем. Patroni использует максимальную реплику LSN, если имеется более одного последователя, в противном случае она будет использовать текущую LSN Wal-лидера. По умолчанию установлено значение -1, Patroni не предпримет действий по замене синхронного нездорового последователя при значении равном нулю или ниже. Установите значение достаточно высоким, чтобы Patroni не менял синхронных последователей слишком часто во время высокой нагрузки транзакций.
max_timelines_history – максимальное количество элементов истории временных линий, хранящихся в DCS. Значение по умолчанию: 0. Когда установлено значение 0, сохраняется полная история в DCS.
primary_start_timeout – количество времени, в течение которого основному серверу разрешается восстанавливаться после сбоев до того, как произойдет отказ (в секундах). По умолчанию 300 секунд. При установке значения 0 отказ происходит сразу же после обнаружения сбоя, если это возможно. При использовании асинхронной репликации отказ может привести к потере транзакций. Наихудшее время отказа основного сервера составляет: loop_wait + primary_start_timeout + loop_wait, если только primary_start_timeout не равен нулю, в этом случае это просто loop_wait. Установите значение в соответствии с компромиссом между устойчивостью и доступностью.
primary_stop_timeout – количество секунд, в течение которых Patroni разрешено ожидать при остановке PostgreSQL, и оно эффективно только тогда, когда включен режим синхронности. Если установлено значение > 0 и включен режим синхронности, Patroni отправляет сигнал SIGKILL постмастеру, если операция остановки выполняется дольше, чем значение, установленное параметром primary_stop_timeout. Установите значение в соответствии с компромиссом между устойчивостью и доступностью. Если параметр не установлен или установлен <= 0, то primary_stop_timeout не применяется.
synchronous_mode – включает режим синхронной репликации. В этом режиме выбирается синхронная копия, и только последний лидер и синхронная копия могут участвовать в выборах лидера. Синхронный режим гарантирует, что успешно завершенные транзакции не будут потеряны при отказе, за счет потери доступности для записи, когда Patroni не может обеспечить устойчивость транзакций. См. документацию о режимах репликации для получения подробной информации.
synchronous_mode_strict – предотвращает отключение синхронной репликации, если нет доступных синхронных копий, блокируя все клиентские записи на основном узле. См. документацию о режимах репликации для получения подробной информации.
failsafe_mode – включает Режим отказоустойчивости DCS. По умолчанию установлено значение false.
postgresql –
- use_pg_rewind – использовать ли pg_rewind. По умолчанию установлено значение false.
- use_slots – использовать ли слоты репликации. По умолчанию установлено значение true для PostgreSQL 9.4+.
- recovery_conf – дополнительные параметры конфигурации, записываемые в recovery.conf при настройке ведомого сервера. В PostgreSQL 12 больше нет файла recovery.conf, но можно продолжать использовать этот раздел, потому что Patroni обрабатывает его прозрачно.
- parameters – список параметров настройки для PostgreSQL.
- pg_hba – список строк, которые Patroni будет использовать для генерации pg_hba.conf. Patroni игнорирует этот параметр, если параметр hba_file PostgreSQL установлен в нестандартное значение:
  - - host all all 0.0.0.0/0 md5.
  - - host replication replicator 127.0.0.1/32 md5 – строка, подобная этой, необходима для репликации.
- pg_ident – список строк, которые Patroni будет использовать для генерации pg_ident.conf. Patroni игнорирует этот параметр, если ident_file параметр PostgreSQL установлен на значение, отличное от значения по умолчанию:
  - - mapname1 systemname1 pguser1.
  - - mapname1 systemname2 pguser2.
standby_cluster – если этот раздел определен, то это означает, что необходимо загрузить резервный кластер.
- host – адрес удаленного узла.
- port – порт удаленного узла.
- primary_slot_name – какой слот на удаленном узле следует использовать для репликации. Этот параметр является необязательным, значение по умолчанию выводится из имени экземпляра (см. функцию slot_name_from_member_name).
- create_replica_methods – упорядоченный список методов, которые могут быть использованы для загрузки резервного лидера с удаленного основного сервера, может отличаться от списка, определенного в PostgreSQL.
- restore_command – команда для восстановления записей WAL с удаленного основного узла на узлы в кластере-резерве, может отличаться от списка, определенного в PostgreSQL.
- archive_cleanup_command – команда очистки для ведущего резервного узла.
- recovery_min_apply_delay – сколько времени нужно подождать перед фактическим применением записей WAL на ведущем резервном узле.
slots – определение постоянных слотов репликации. Эти слоты будут сохранены во время переключения/сбоя. Постоянные слоты, которых не существует, будут созданы Patroni. Начиная с PostgreSQL 11 постоянные физические слоты создаются на всех узлах и их положение обновляется каждые loop_wait секунды. Для версий PostgreSQL старше 11 постоянные физические слоты репликации поддерживаются только на текущем основном узле. Логические слоты копируются с основного узла на резервный при перезапуске, а затем их позиция обновляется каждые loop_wait секунд (при необходимости). Копирование файлов логического слота выполняется через соединение libpq и использование либо функции отката, либо учетных данных суперпользователя (см. раздел postgresql.authentication). Всегда есть вероятность того, что позиция логического слота на реплике немного отстает от бывшей основной, поэтому приложение должно быть готово к тому, что некоторые сообщения могут быть получены повторно после сбоя. Самый простой способ сделать это - отслеживать confirmed_flush_lsn. Включение постоянных слотов репликации требует, чтобы postgresql.use_slots было установлено на true. Если определены постоянные слоты логической репликации, Patroni автоматически включит hot_standby_feedback. Поскольку отказоустойчивость логических слотов репликации небезопасна в PostgreSQL 9.6 и более ранних версиях, а в версии PostgreSQL 10 отсутствуют некоторые важные функции, эта функция работает только с PostgreSQL 11+.
- my_slot_name – имя постоянного слота репликации. Если имя постоянного слота совпадает с именем текущего узла, он не будет создан на этом узле. Если добавить постоянный физический слот репликации, имя которого совпадает с именем члена Patroni, Patroni обеспечит, чтобы созданный слот не был удален даже в том случае, если соответствующий член станет недоступным, ситуация, которая обычно приводит к удалению слота Patroni. Хотя это может быть полезно в некоторых ситуациях, например, когда необходимо, чтобы слоты репликации, используемые членами, сохранялись во время временных сбоев или при импорте существующих членов в новый кластер Patroni (см. Преобразование автономного сервера в кластер Patroni для получения подробной информации), оператор должен соблюдать осторожность, чтобы эти совпадения имен не сохранялись в DCS, когда слот больше не требуется из-за его влияния на нормальное функционирование Patroni.
  - type – тип слота. Может быть physical или logical. Если слот является логическим, также необходимо определить database и plugin.
  - database – имя базы данных, в которой должны быть созданы логические слоты.
  - plugin – имя плагина для логического слота.
ignore_slots – список наборов свойств слотов репликации, для которых Patroni должен игнорировать совпадающие слоты. Эта конфигурация полезна, когда некоторые слоты репликации управляются вне Patroni. Любое подмножество совпадающих свойств приведет к тому, что слот будет проигнорирован.
- name – имя слота репликации.
- type – тип слота. Может быть physical или logical. Если слот логический, можно определить database и/или plugin.
- database – имя базы данных (при сопоставлении слота logical).
- plugin – плагин логической декодировки (при сопоставлении слота logical).

slots - это хеш-карта, а ignore_slots - массив. Например:

slots:
  permanent_logical_slot_name:
    type: logical
    database: my_db
    plugin: test_decoding
  permanent_physical_slot_name:
    type: physical
  ...
ignore_slots:
  - name: ignored_logical_slot_name
    type: logical
    database: my_db
    plugin: test_decoding
  - name: ignored_physical_slot_name
    type: physical
  ...

Если топология кластера статична (фиксированное количество узлов, которые никогда не меняют свои имена), можно настроить постоянные физические слоты репликации с именами, соответствующими именам узлов, чтобы избежать переработки файлов WAL при временном отключении реплики:

slots:
  node_name1:
    type: physical
  node_name2:
    type: physical
  node_name3:
    type: physical
  ...

примечание

Постоянные слоты репликации синхронизируются только от primary/standby_leader до узлов-реплик. Это означает, что приложения должны использовать их только из ведущего узла. Использование их на узлах-репликах вызовет бесконечный рост pg_wal на всех остальных узлах в кластере. Исключение составляют постоянные физические слоты, соответствующие именам членов Patroni, если таковые имеются. Они будут синхронизироваться между всеми узлами, поскольку они используются для репликации между ними.