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

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

примечание

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

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

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

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

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

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

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

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

В чем разница между Patroni и другими решениями высокой доступности в отношении управления PostgreSQL?​

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

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

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

Вот почему Patroni называется «шаблоном для решений высокой доступности». Он идет дальше простого управления физической репликацией: он управляет всем PostgreSQL.

DCS​

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

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

До тех пор, пока не возникает конфликтов пространств имен и областей действия в разных кластерах Patroni, имеется возможность возможность использовать один и тот же кластер DCS для хранения информации из нескольких кластеров Patroni.

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

Второй кластер Patroni, который пытается использовать одни и те же namespace и scope, не сможет управлять PostgreSQL, поскольку он обнаружит информацию, связанную с этой же комбинацией в DCS, но с несовместимым идентификатором системы PostgreSQL. Несоответствие системного идентификатора приводит к тому, что 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, которая хранится внутри каталога данных PostgreSQL каждого члена кластера Patroni.

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

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

Помните: 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 и какой приоритет у них?​

Существующие типы:

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

Примечание:

Некоторые параметры конфигурации PostgreSQL (GUC) могут быть установлены только глобально, то есть через динамическую конфигурацию. Кроме того, существуют GUC, для которых Patroni принудительно устанавливает жестко заданное значение.

См. подробнее в конфигурации Patroni.

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

Да, есть.

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

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

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

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

См. следующий вопрос для получения более подробной информации.

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

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

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

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

  • Отправьте POST-запрос на конечную точку REST API Reload;

  • Выполните команду 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.

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

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

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

Что происходит, если я изменю параметр GUC в PostgreSQL, требующий перезапуска?​

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

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

Примечание:

Некоторые GUC-параметры в PostgreSQL требуют особого управления с точки зрения порядка перезапуска узлов PostgreSQL. Обратитесь к разделу PostgreSQL, параметры, которые касаются общей памяти, для получения более подробной информации.

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

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

Обратите внимание, что информация, хранящаяся с помощью версии API 2, не управляется версией API 3 и наоборот.

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

  • Версия API 2 отключена по умолчанию начиная с Etcd версии 3.4;
  • Версия API 2 будет полностью удалена в Etcd версии 3.6.

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

Можно настроить постоянный физический слот репликации для членов кластера.

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

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

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

Примечание:

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

Примечание:

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

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

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

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

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

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

Примечание:

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

Управление PostgreSQL​

Могу ли я изменить GUC-параметры PostgreSQL непосредственно в конфигурации PostgreSQL?​

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

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

Есть несколько вариантов преодоления управления, осуществляемого Patroni:

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

За более подробной информацией об этом обратитесь к разделу Важные правила.

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

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

Нет, не нужно пытаться управлять PostgreSQL напрямую!

Любая попытка перезагрузки сервера PostgreSQL без Patroni может привести к тому, что кластер столкнется с отказами.

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

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

Да, может.

Обратитесь к разделу Преобразование Standalone-сервера в кластер Patroni для получения подробных инструкций.

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

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

Учитывая это, необходимо отключить любые другие источники, которые могут управлять кластерами PostgreSQL, такие как системные единицы, например, postgresql.service. Только Patroni должен иметь возможность запускать, останавливать и продвигать экземпляры PostgreSQL в кластере. Несоблюдение этого требования может привести к сценариям split-brain. Например, если узел, работающий в качестве основного, выйдет из строя, а блок postgresql.service будет включен, он может снова запустить PostgreSQL и вызвать split-brain.

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

Какие приложения являются частью Patroni?​

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

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

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

Это кластер, в котором нет ни одного основного узла PostgreSQL, то есть в кластере нет ни одного участника, работающего в режиме чтения/записи.

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

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

Примечание:

Резервный кластер ничего не знает о кластере-источнике, с которого он реплицируется – он может даже использовать restore_command вместо WAL streaming, и может использовать абсолютно независимый кластер DCS.

Обратитесь к разделу Резервный кластер для получения более подробной информации.

Что такое leader в Patroni?​

leader в Patroni - это как координатор кластера.

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

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

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

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

Необходимо поминить что Patroni отделен от DCS.

Что означает pause в Patroni?​

pause – это операция, предоставляемая Patroni, чтобы пользователь мог попросить Patroni временно прекратить управление PostgreSQL.

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

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

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

Как работает механизм автоматического переключения Patroni?​

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

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

Этот leader блокировка имеет время жизни, связанное с ней. Если ведущий узел не обновляет аренду leader блокировки вовремя, ключ в конечном итоге истечет из DCS.

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

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

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

Да, можно.

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

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

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

Инициализация и создание резервных копий​

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

По умолчанию Patroni будет использовать initdb для инициализации новой кластерной системы и pg_basebackup для создания узлов-резервных копий из копии члена кластера leader.

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

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

Для получения подробной информации обратитесь к разделам Инициализация и Создание реплик.

Мониторинг​

Как я могу контролировать свой кластер Patroni?​

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

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

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