Перейти к основному содержимому

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

примечание

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

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

Для изменения динамической конфигурации можно использовать либо инструмент patronictl edit-config, либо Patroni REST API.

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

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

loop_wait + 2 * retry_timeout <= ttl

  • maximum_lag_on_failover: максимальное отставание в байтах, при котором реплика все еще может участвовать в выборах лидера.

  • maximum_lag_on_syncnode: максимальное отставание в байтах синхронной реплики, после которого она считается нездоровым кандидатом и заменяется здоровой асинхронной репликой. Patroni использует максимальный LSN реплики, если реплик несколько, в противном случае используется текущий WAL LSN лидера. Значение по умолчанию: -1. Patroni не будет предпринимать действий для замены нездоровой синхронной реплики, если значение установлено в 0 или ниже. Пожалуйста, устанавливайте значение достаточно высоким, чтобы Patroni не заменял синхронную реплику слишком часто при высокой нагрузке транзакций.

  • max_timelines_history: максимальное количество записей истории timeline, сохраняемых в DCS. Значение по умолчанию: 0. При значении 0 сохраняется полная история в DCS.

  • primary_start_timeout: время, отведенное первичному узлу на восстановление после сбоев перед запуском failover (в секундах). Значение по умолчанию: 300 секунд. При значении 0 failover выполняется немедленно после обнаружения сбоя, если это возможно. При использовании асинхронной репликации failover может привести к потере транзакций. Худший случай времени failover при отказе лидера: loop_wait + primary_start_timeout + loop_wait, за исключением случая, когда primary_start_timeout равно нулю, тогда это просто loop_wait. Устанавливайте значение в соответствии с вашим компромиссом между надежностью и доступностью.

  • primary_stop_timeout: количество секунд, которое Patroni может ожидать при остановке Postgres; эффективно только при включенном synchronous_mode. При значении > 0 и включенном synchronous_mode Patroni отправляет SIGKILL процессу postmaster, если операция остановки выполняется дольше времени, заданного в primary_stop_timeout. Устанавливайте значение в соответствии с вашим компромиссом между надежностью и доступностью. Если параметр не задан или установлен <= 0, primary_stop_timeout не применяется.

  • synchronous_mode: включает режим синхронной репликации. Возможные значения: off, on, quorum. В этом режиме лидер управляет параметром synchronous_standby_names, и только последний известный лидер или одна из синхронных реплик могут участвовать в выборах лидера. Синхронный режим гарантирует, что успешно зафиксированные транзакции не будут потеряны при failover, ценой потери доступности на запись, когда Patroni не может гарантировать долговечность транзакций. Подробнее смотрите документацию по режимам репликации.

  • synchronous_mode_strict: предотвращает отключение синхронной репликации, если синхронные реплики недоступны, блокируя все клиентские запросы на запись к первичному узлу. Подробнее смотрите документацию по режимам репликации.

  • synchronous_node_count: если synchronous_mode включен, этот параметр используется Patroni для управления точным количеством синхронных standby-экземпляров и корректирует состояние в DCS и параметр synchronous_standby_names в PostgreSQL при подключении и отключении участников. Если параметр установлен на значение, превышающее количество доступных узлов, оно будет автоматически скорректировано. Значение по умолчанию: 1.

  • failsafe_mode: включает Режим отказоустойчивости DCS. Значение по умолчанию: false.

  • postgresql:

    • use_pg_rewind: использовать ли pg_rewind. Значение по умолчанию: false. Обратите внимание, что кластер должен быть инициализирован с контрольными суммами страниц данных (--data-checksums для initdb) и/или wal_log_hints должен быть установлен в on, иначе pg_rewind не будет работать.
    • use_slots: использовать ли слоты репликации. Значение по умолчанию: true для PostgreSQL 9.4+.
    • recovery_conf: дополнительные настройки конфигурации, записываемые в recovery.conf при настройке реплики. В PostgreSQL 12 recovery.conf больше не существует, но этот раздел можно продолжать использовать, так как Patroni обрабатывает его прозрачно.
    • parameters: параметры конфигурации (GUC) для Postgres в формате {max_connections: 100, wal_level: "replica", max_wal_senders: 10, wal_log_hints: "on"}. Многие из них необходимы для работы репликации.
    • pg_hba: список строк, которые Patroni будет использовать для генерации pg_hba.conf. Patroni игнорирует этот параметр, если параметр PostgreSQL hba_file установлен в значение, отличное от значения по умолчанию.
      • - 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 игнорирует этот параметр, если параметр PostgreSQL ident_file установлен в значение, отличное от значения по умолчанию.
      • - mapname1 systemname1 pguser1
      • - mapname1 systemname2 pguser2

  • standby_cluster: если этот раздел определен, требуется создать резервный кластер (standby).

    • host: адрес удаленного узла.
    • port: порт удаленного узла.
    • primary_slot_name: какой слот на удаленном узле использовать для репликации. Этот параметр необязателен, значение по умолчанию выводится из имени экземпляра (смотрите функцию slot_name_from_member_name).
    • create_replica_methods: упорядоченный список методов, которые могут использоваться для инициализации лидера standby из удаленного лидера, может отличаться от списка, определенного в postgresql_settings
    • restore_command: команда для восстановления записей WAL с удаленного лидера на узлы в кластере standby, может отличаться от списка, определенного в postgresql_settings.
    • archive_cleanup_command: команда очистки для лидера standby
    • recovery_min_apply_delay: сколько времени ждать перед фактическим применением записей WAL на лидере standby

  • member_slots_ttl: время (TTL - Time To Live) хранения физических репликационных слотов для недоступных узлов. Установите 0, если хотите сохранить старое поведение (когда ключ участника истекает в DCS, слот удаляется немедленно). Функция работает только начиная с PostgreSQL 11.

    Основные характеристики:

    • Назначение: предотвращает удаление слотов репликации сразу после исчезновения участника (member key) из DCS (etcd/consul), что позволяет узлу вернуться без полной синхронизации данных.
    • Поведение: слоты сохраняются в течение времени, заданного этим параметром, после чего удаляются.
    • Значение по умолчанию: обычно составляет 30min (30 минут).
    • Тип конфигурации: динамический параметр Patroni, задается в секции slots или глобально.

  • slots: определение постоянных слотов репликации. Эти слоты будут сохранены при switchover/failover. Постоянные слоты, которых не существует, будут созданы Patroni. Начиная с PostgreSQL 11 постоянные физические слоты создаются на всех узлах, и их позиция продвигается каждые loop_wait секунд. Для версий PostgreSQL старше 11 постоянные физические слоты репликации поддерживаются только на текущем лидере. Логические слоты копируются с лидера на standby с перезапуском, после чего их позиция продвигается каждые loop_wait секунд (при необходимости). Копирование файлов логических слотов выполняется через соединение libpq и с использованием учетных данных rewind или суперпользователя (смотрите раздел postgresql.authentication). Всегда существует вероятность того, что позиция логического слота на реплике будет немного отставать от бывшего лидера, поэтому приложение должно быть готово к тому, что некоторые сообщения могут быть получены повторно после failover. Самый простой способ справиться с этим — отслеживание confirmed_flush_lsn. Включение постоянных слотов репликации требует установки postgresql.use_slots в true. Если определены постоянные логические слоты репликации, Patroni автоматически включит hot_standby_feedback. Поскольку failover логических слотов репликации небезопасен в PostgreSQL 9.6 и старше, а в PostgreSQL 10 отсутствуют некоторые важные функции, данная возможность работает только с PostgreSQL 11+.

    • my_slot_name: имя постоянного слота репликации. Если имя постоянного слота совпадает с именем текущего узла, он не будет создан на этом узле. Если добавляется постоянный физический слот репликации, имя которого совпадает с именем участника Patroni, Patroni гарантирует, что созданный слот не будет удален, даже если соответствующий участник станет неотзывчивым, что в норме привело бы к удалению слота Patroni. Хотя это может быть полезно в некоторых ситуациях, например, когда требуется, чтобы слоты репликации, используемые участниками, сохранялись во время временных сбоев или при импорте существующих участников в новый кластер Patroni (подробнее смотрите Преобразование автономного кластера в кластер Patroni), оператор должен проявлять осторожность, чтобы эти конфликты имен не сохранялись в DCS, когда слот больше не требуется, из-за их влияния на нормальную работу Patroni.
      • type: тип слота. Может быть physical или logical. Если слот логический, необходимо дополнительно определить database и plugin. Если слот физический, можно дополнительно определить cluster_type.
      • database: имя базы данных, где должны быть созданы логические слоты.
      • plugin: имя плагина для логического слота.
      • cluster_type: тип кластера (primary или standby), на котором должен быть создан слот, в противном случае он не будет создан или уже существующий слот будет удален.

  • 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
примечание

При запуске PostgreSQL v11 или новее Patroni поддерживает физические слоты репликации на всех узлах, которые потенциально могут стать лидером, чтобы узлы-реплики сохраняли зарезервированные WAL-сегменты, если они потенциально потребуются другим узлам. В случае, если узел отсутствует и его ключ участника истекает в DCS, соответствующий слот репликации удаляется после member_slots_ttl (значение по умолчанию 30min). Можно увеличить или уменьшить время хранения в зависимости от потребностей. В качестве альтернативы, если топология кластера статична (фиксированное количество узлов, которые никогда не меняют свои имена), можно настроить постоянные физические слоты репликации с именами, соответствующими именам узлов, чтобы избежать удаления слотов и переработки WAL-файлов, пока реплика временно не работает:

slots:
  node_name1:
    type: physical
  node_name2:
    type: physical
  node_name3:
    type: physical
warning

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

warning

Установка тега nostream на standby отключает копирование и синхронизацию постоянных логических слотов репликации на самом узле и на всех его каскадных репликах, если они есть.