Часто задаваемые вопросы

примечание

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

В этом разделе можно найти ответы на наиболее часто задаваемые вопросы о Patroni. Каждый подраздел посвящен разным типам вопросов.

Сравнение с другими решениями высокой доступности

Почему Patroni требует отдельный кластер узлов DCS, в то время как другие решения, такие как repmgr, — нет?

Существуют разные способы реализации HA-решений, каждый со своими плюсами и минусами.

Программное обеспечение, такое как repmgr, выполняет обмен данными между узлами для принятия решений о том, когда следует предпринимать действия.

Patroni, с другой стороны, полагается на состояние, хранящееся в DCS. DCS выступает в качестве источника истины для Patroni, чтобы решать, что ему делать.

Хотя наличие отдельного кластера DCS может усложнить архитектуру, такой подход также снижает вероятность возникновения сценариев split-brain в кластере Postgres.

В чем разница между Patroni и другими HA-решениями в отношении управления Postgres?

Patroni не просто управляет высокой доступностью кластера Postgres, но и управляет самим Postgres.

Если узлы Postgres еще не существуют, он занимается бутстрапом первичного и standby-узлов, а также управляет конфигурацией Postgres на узлах. Если узлы Postgres уже существуют, Patroni возьмет на себя управление кластером.

Помимо вышеперечисленного, Patroni также обладает возможностями самовосстановления. Другими словами, если первичный узел выходит из строя, Patroni не только выполнит failover на реплику, но и попытается повторно присоединить бывший первичный узел как реплику нового первичного. Аналогично, если реплика выходит из строя, Patroni попытается повторно присоединить эту реплику.

Именно поэтому Patroni называется «шаблоном для HA-решений». Он идет дальше, чем просто управление физической репликацией: он управляет Postgres в целом.

DCS

Могу ли я использовать один и тот же кластер etcd для хранения данных двух или более кластеров Patroni?

Да, можно!

Информация о кластере Patroni хранится в DCS по пути с префиксом, заданным настройками Patroni namespace и scope.

Пока нет конфликтов по namespace и scope между разными кластерами Patroni, можно использовать один и тот же кластер DCS для хранения информации от нескольких кластеров Patroni.

Что произойдет, если я попытаюсь использовать одну и ту же комбинацию namespace и scope для разных кластеров Patroni, указывающих на один и тот же кластер DCS?

Второй кластер Patroni, который попытается использовать те же namespace и scope, не сможет управлять Postgres, потому что он найдет информацию, связанную с этой же комбинацией в DCS, но с несовместимым системным идентификатором Postgres.

Несоответствие системного идентификатора приводит к тому, что Patroni прерывает управление вторым кластером, так как предполагает, что это относится к другому кластеру и что пользователь неправильно настроил Patroni.

Убедитесь, что используются разные namespace / scope при работе с разными кластерами Patroni, использующими один и тот же кластер DCS.

Что произойдет, если я потеряю свой кластер DCS?

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

Самым первым последствием является то, что все кластеры Patroni, зависящие от этого DCS, перейдут в режим только для чтения — если только не включен Режим отказоустойчивости DCS.

Что делать, если потерян кластер DCS?

Существует три возможных исхода при потере кластера DCS:

1. Кластер DCS полностью восстановлен: это не требует никаких действий со стороны Patroni. Как только кластер DCS будет восстановлен, Patroni также должен восстановиться;
2. Кластер DCS пересоздан на месте, и конечные точки остаются теми же. Никаких изменений со стороны Patroni не требуется;
3. Создан новый кластер DCS с другими конечными точками. Необходимо обновить конечные точки DCS в конфигурации Patroni каждого узла Patroni.

Если произошел сценарий 2. или 3., Patroni позаботится о повторном создании информации о статусе на основе текущего состояния кластера и воссоздаст динамическую конфигурацию в DCS на основе резервного файла с именем patroni.dynamic.json, который хранится внутри каталога данных Postgres каждого участника кластера Patroni.

Что произойдет, если я потеряю большинство в моем кластере DCS?

DCS станет неотзывчивым, что приведет к тому, что Patroni понизит текущий узел Postgres с правами чтения/записи.

Помните: Patroni полагается на состояние DCS для принятия действий в кластере.

Использовать Режим отказоустойчивости DCS, чтобы смягчить эту ситуацию.

patronictl

Нужно ли запускать patronictl на хосте Patroni?

Нет, этого делать не требуется.

Запуск patronictl на хосте Patroni удобен, если есть доступ к хосту Patroni, потому что можно использовать тот же файл конфигурации от агента patroni для приложения patronictl.

Однако patronictl — это по сути клиент, и его можно запускать с удаленных машин. Требуется предоставить ему достаточную конфигурацию, чтобы он мог достичь DCS и REST API участника(ов) Patroni.

Почему информация об одном из моих участников Patroni исчезла из вывода команды patronictl list?

Информация, отображаемая командой patronictl list, основана на содержимом DCS.

Если информация об участнике исчезла из DCS, очень вероятно, что агент Patroni на этом узле больше не работает или не может связаться с DCS.

Поскольку участник не может обновлять информацию, она в конечном итоге истекает в DCS, и, следовательно, участник больше не отображается в выводе команды patronictl list.

Почему информация об одном из моих участников Patroni не актуальна в выводе команды patronictl list?

Информация, отображаемая командой patronictl list, основана на содержимом DCS.

По умолчанию эта информация обновляется Patroni примерно каждые loop_wait секунд. Другими словами, даже если все работает нормально, может наблюдаться «задержка» до loop_wait секунд в информации, хранящейся в DCS.

Имейте в виду, что это не правило. Некоторые операции, выполняемые Patroni, приводят к немедленному обновлению информации в DCS.

Конфигурация

В чем разница между динамической конфигурацией и локальной конфигурацией?

Динамическая конфигурация (или глобальная конфигурация) — это конфигурация, хранящаяся в DCS и применяемая ко всем участникам кластера Patroni. Здесь в первую очередь следует хранить конфигурацию.

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

Подробнее смотрите в разделе Конфигурация Patroni.

Какие типы конфигурации существуют в Patroni и каков их приоритет?

Типы:

• Динамическая конфигурация: применяется ко всем участникам;
• Локальная конфигурация: применяется к локальному участнику, переопределяет динамическую конфигурацию;
• Конфигурация через переменные окружения: применяется к локальному участнику, переопределяет как динамическую, так и локальную конфигурацию.

Примечание: некоторые GUC Postgres могут быть заданы только глобально, то есть через динамическую конфигурацию. Кроме того, есть GUC, для которых Patroni устанавливает жестко закодированное значение.

Подробнее смотрите в разделе Конфигурация Patroni.

Есть ли инструмент, который поможет создать файл конфигурации Patroni?

Да, есть.

Можно использовать команды patroni --generate-sample-config или patroni --generate-config для генерации примера конфигурации Patroni или конфигурации Patroni на основе существующего экземпляра Postgres соответственно.

Подробнее смотрите в разделах Пример конфигурации Patroni и Конфигурация Patroni для запущенного экземпляра.

Я изменил параметры в разделе bootstrap.dcs, но Patroni не применяет изменения к участникам кластера. В чем проблема?

Значения, настроенные в разделе bootstrap.dcs, используются только при бутстрапе нового кластера. Эти значения будут записаны в DCS во время бутстрапа.

После завершения фазы бутстрапа изменить динамическую конфигурацию можно только через DCS.

Подробнее смотрите в следующем вопросе.

Как изменить динамическую конфигурацию?

Необходимо изменить конфигурацию в DCS. Это можно сделать либо через:

• patronictl edit-config или
• Запрос PATCH к конечной точке config.

Как я могу изменить свою локальную конфигурацию?

Необходимо изменить файл конфигурации соответствующего участника Patroni и отправить сигнал агенту Patroni SIGHUP. Это можно сделать одним из следующих способов:

• Отправить запрос POST к конечной точке reload REST API или;

• Запустить patronictl reload или;

• Локально отправить сигнал процессу Patroni SIGHUP:

  • Если Patroni запущен через systemd, можно использовать команду systemctl reload PATRONI_UNIT.service, где PATRONI_UNIT — имя службы Patroni или;
  • Если Patroni запущен другим способом, необходимо идентифицировать процесс patroni и выполнить kill -s HUP PID, где PID — идентификатор процесса patroni.

Примечание: в некоторых случаях перезагрузка через patronictl reload может не сработать:

• Истек срок действия сертификатов REST API: это можно смягчить, используя опцию -k утилиты patronictl;
• Неверные учетные данные: например, при изменении учетных данных restapi или ctl в файле конфигурации и использовании того же файла конфигурации для Patroni и patronictl.

Как я могу изменить конфигурацию через переменные окружения?

Конфигурация через переменные окружения считывается Patroni только во время запуска.

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

Позаботьтесь о том, чтобы не вызвать failover в кластере! Возможно, будет интересно ознакомиться с разделом patronictl pause.

Как уменьшить количество повторяющихся строк в логах пульсации во время нормальной работы?

Если логи слишком загромождены повторяющимися строками, такими как «Lock owner: ...» и «no action. I am ...», настройте параметр log.deduplicate_heartbeat_logs: true.

Можно установить его либо в файле Patroni YAML, либо с помощью параметра PATRONI_LOG_DEDUPLICATE_HEARTBEAT_LOGS=true.

Имейте в виду, что это уменьшает объем логов за счет подавления повторяющихся сообщений пульсации, но также теряется возможность отслеживания пульсации для каждого цикла, что может помочь при диагностике отказоустойчивости.

Что произойдет, если я изменю GUC Postgres, требующий перезагрузки (reload)?

Когда изменяется динамическая или локальная конфигурация, как объяснено в предыдущих вопросах, Patroni позаботится о перезагрузке конфигурации Postgres.

Что произойдет, если я изменю GUC Postgres, требующий перезапуска (restart)?

Patroni пометит затронутые участников флагом pending restart.

Решение о том, когда и как перезапускать участников, принимается оператором. Это можно сделать либо через:

• patronictl restart; или
• Запрос POST к конечной точке restart.

Примечание: некоторые GUC Postgres требуют особого управления в отношении порядка перезапуска узлов Postgres. Подробнее смотрите в разделе Параметры PostgreSQL, затрагивающие общую память.

В чем разница между etcd и etcd3 в конфигурации Patroni?

etcd использует API версии 2 от etcd, тогда как etcd3 использует API версии 3 от etcd.

Имейте в виду, что информация, сохраненная через API версии 2, не управляется через API версии 3, и наоборот.

Рекомендуем настраивать etcd3 вместо etcd, потому что:

• API версии 2 отключен по умолчанию начиная с etcd v3.4;
• API версии 2 будет полностью удален в etcd v3.6.

У меня включен use_slots в конфигурации Patroni, но когда участник кластера уходит в оффлайн на некоторое время, слот репликации, используемый этим участником, удаляется на вышестоящем узле. Что я могу сделать, чтобы избежать этой проблемы?

Есть два варианта:

1. Можно настроить member_slots_ttl (значение по умолчанию 30min, доступно начиная с Patroni 4.0.0 и PostgreSQL 11 и новее), и слоты репликации для отсутствующих участников не будут удаляться, если время простоя участников короче настроенного порога.
2. Можно настроить постоянные физические слоты репликации для участников.

Начиная с Patroni 3.2.0 теперь можно иметь слоты участников в виде постоянных слотов, управляемых Patroni.

Patroni создаст постоянные физические слоты на всех узлах и позаботится о том, чтобы не удалять слоты, а также продвигать LSN слотов на всех узлах в соответствии с LSN, который был потреблен участником.

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

Примечание: в Patroni старше 3.2.0 можно было настраивать слоты участников как постоянные физические слоты, однако они управлялись только на текущем лидере. То есть в случае failover/switchover эти слоты создавались бы на новом лидере, но это не гарантировало бы наличие всех WAL-сегментов для отсутствующего узла.

Примечание: даже в Patroni 3.2.0 может возникнуть небольшая гонка условий. В самом начале, когда слот создается на реплике, он может опережать тот же слот на лидере, и в случае, если никто не потребляет слот, все еще есть вероятность, что некоторые файлы могут отсутствовать после failover. Имея это в виду, рекомендуется настроить непрерывное архивирование, что позволяет восстановить необходимые WAL или выполнить PITR.

В чем разница между loop_wait, retry_timeout и ttl?

Patroni периодически выполняет то, что называется циклом HA. В каждом цикле HA выполняется серия проверок кластера для определения его работоспособности, и в зависимости от статуса могут предприниматься действия, например, выполняется failover на standby.

loop_wait определяет, сколько секунд Patroni должен ждать перед выполнением нового цикла проверок HA.

retry_timeout задает таймаут для операций повторных попыток в DCS и в Postgres. Например: если DCS не отвечает более retry_timeout секунд, Patroni может понизить первичный узел в качестве меры безопасности.

ttl задает время аренды блокировки leader в DCS. Если текущий лидер кластера не может обновить аренду блокировки leader в течение своих циклов HA дольше, чем ttl, то аренда истечет, и это запустит гонку лидеров в кластере.

Примечание: при изменении этих настроек имейте в виду, что Patroni применяет правило и минимальные значения, описанные в разделе Динамические настройки конфигурации документации.

Управление PostgreSQL

Могу ли я изменять GUC Postgres напрямую в конфигурации Postgres?

Можно, но этого следует избегать.

Конфигурация Postgres управляется Patroni, и попытки редактировать файлы конфигурации могут закончиться неудачей, так как Patroni может в конечном итоге перезаписать их.

Есть несколько доступных вариантов для обхода управления со стороны Patroni:

• Изменять GUC Postgres через $PGDATA/postgresql.base.conf или;
• Определить postgresql.custom_conf, который будет использоваться вместо postgresql.base.conf, чтобы можно было управлять им внешне или;
• Изменять GUC с помощью ALTER SYSTEM/ALTER DATABASE/ALTER USER.

Подробнее об этом можно найти в разделе Важные правила.

В любом случае рекомендуется управлять всей конфигурацией Postgres через Patroni. Это централизует управление и упростит отладку Patroni при необходимости.

Могу ли я перезапускать узлы Postgres напрямую?

Нет, не следует пытаться управлять Postgres напрямую!

Любая попытка перезапустить сервер Postgres без Patroni может привести к failover'ам в кластере.

Если необходимо управлять сервером Postgres, делайте это через способы, предоставленные Patroni.

Способен ли Patroni взять на себя управление уже существующим кластером Postgres?

Да, можно!

Подробные инструкции смотрите в разделе Преобразование автономного кластера в кластер Patroni.

Как Patroni управляет Postgres?

Patroni отвечает за запуск и остановку Postgres, запуская бинарные файлы Postgres, такие как pg_ctl и postgres.

Имея это в виду, ОБЯЗАТЕЛЬНО отключите любые другие источники, которые могут управлять кластерами Postgres, например, systemd-юниты, например postgresql.service. Только Patroni должен иметь возможность запускать, останавливать и повышать экземпляры Postgres в кластере. Несоблюдение этого может привести к сценариям split-brain. Например: если узел, работающий как первичный, вышел из строя, и юнит postgresql.service включен, он может снова запустить Postgres и вызвать split-brain.

Концепции и требования

Какие приложения входят в состав Patroni?

Patroni по сути поставляет пару приложений:

• patroni: это агент Patroni, который отвечает за управление узлом Postgres;
• patronictl: это утилита командной строки, используемая для взаимодействия с кластером Patroni (выполнение переключений, перезапусков, изменений в конфигурации и так далее). Подробнее смотрите в разделе patronictl.

Что такое standby cluster в Patroni?

Это кластер, в котором не запущен ни один первичный узел Postgres, то есть в кластере нет участника с правами чтения/записи.

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

В кластере будет лидер, который будет standby, ответственным за репликацию изменений с удаленного узла Postgres. Затем будет набор standby, настроенных с каскадной репликацией от этого лидера.

Примечание: standby-кластер ничего не знает об исходном кластере, из которого он реплицирует — он может даже использовать restore_command вместо потоковой передачи WAL и может использовать абсолютно независимый кластер DCS.

Подробнее смотрите в разделе Резервный кластер (Standby cluster).

Что такое лидер в Patroni?

Лидер в Patroni — это своего рода координатор кластера.

В обычном кластере Patroni лидер будет узлом с правами чтения/записи.

В standby-кластере Patroni лидер (он же standby leader) будет отвечать за репликацию с удаленного узла Postgres и каскадную передачу этих изменений другим участникам standby-кластера.

Требует ли Patroni минимального количества узлов Postgres в кластере?

Нет, можно запускать Patroni с любым количеством узлов Postgres.

Помните: Patroni отделен от DCS.

Что означает пауза (pause) в Patroni?

Пауза — это операция, предоставляемая Patroni, чтобы пользователь мог попросить Patroni отступить в отношении управления Postgres.

Это в основном полезно, когда требуется выполнить обслуживание кластера и нужно избежать того, чтобы Patroni принимал решения, связанные с HA, например, выполнял failover на standby, когда останавливается первичный узел.

Подробнее об этом можно найти в разделе Режим паузы/возобновления для кластера.

Автоматический failover

Как работает механизм автоматического failover в Patroni?

Автоматический failover Patroni основан на том, что называется гонкой лидеров.

Patroni хранит статус кластера в DCS, среди них блокировку лидера, которая содержит имя участника Patroni, который является текущим лидером кластера.

У этой блокировки лидера есть связанное с ней время жизни. Если узел-лидер не успевает обновить аренду блокировки лидера вовремя, ключ в конечном итоге истечет в DCS.

Когда блокировка лидера истекает, это запускает то, что Patroni называет гонкой лидеров: все узлы начинают выполнять проверки, чтобы определить, являются ли они лучшими кандидатами для принятия роли лидера. Некоторые из этих проверок включают вызовы REST API всех других участников Patroni.

Все участники Patroni, которые считают себя лучшими кандидатами для захвата блокировки лидера, попытаются это сделать. Первый участник Patroni, который сможет захватить блокировку лидера, повысит себя до узла с правами чтения/записи (или standby leader), а остальные будут настроены следовать за ним.

Могу ли я временно отключить автоматический failover в кластере Patroni?

Да, можно!

Можно добиться этого, временно поставив кластер на паузу. Это обычно полезно для выполнения обслуживания.

Когда потребуется возобновить автоматический failover кластера, его просто нужно снять с паузы.

Подробнее об этом можно найти в разделе Режим паузы/возобновления для кластера.

Инициализация и создание standby

Как Patroni создает первичный узел Postgres? А как насчет standby-узла Postgres?

По умолчанию Patroni будет использовать initdb для бутстрапа нового кластера и pg_basebackup для создания standby-узлов из копии участника лидера.

Поведение можно настроить, написав свои собственные методы бутстрапа и свои собственные методы создания реплик.

Пользовательские методы обычно полезны, когда требуется восстановить резервные копии, созданные инструментами резервного копирования, такими как pgBackRest или Barman, например.

Подробную информацию смотрите в разделах Пользовательский бутстрап и Пользовательское создание реплик.

Мониторинг

Как можно мониторить кластер Patroni?

Patroni предоставляет несколько удобных конечных точек в своем REST API:

• /metrics: предоставляет метрики мониторинга в формате, который может потребляться Prometheus;
• /patroni: предоставляет статус кластера в формате JSON. Информация, отображаемая здесь, очень похожа на то, что показывает конечная точка /metrics.

Эти конечные точки можно использовать для реализации проверок мониторинга.