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

Преобразование Standalone-сервера в кластер Patroni

примечание

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

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

Процедура​

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

  1. Создайте пользователей PostgreSQL, как объяснено для раздела аутентификации конфигурации Patroni. Ниже приведен пример SQL-команд для создания пользователей в блоке кода, где нужно заменить имена пользователей и пароли в соответствии с текущей средой. Если соответствующие пользователи уже настроены, то можно пропустить этот шаг:

    -- Patroni superuser
    -- Replace PATRONI_SUPERUSER_USERNAME and PATRONI_SUPERUSER_PASSWORD accordingly
    CREATE USER PATRONI_SUPERUSER_USERNAME WITH SUPERUSER ENCRYPTED PASSWORD 'PATRONI_SUPERUSER_PASSWORD';

    -- Patroni replication user
    -- Replace PATRONI_REPLICATION_USERNAME and PATRONI_REPLICATION_PASSWORD accordingly
    CREATE USER PATRONI_REPLICATION_USERNAME WITH REPLICATION ENCRYPTED PASSWORD 'PATRONI_REPLICATION_PASSWORD';

    -- Patroni rewind user, if you intend to enable use_pg_rewind in your Patroni configuration
    -- Replace PATRONI_REWIND_USERNAME and PATRONI_REWIND_PASSWORD accordingly
    CREATE USER PATRONI_REWIND_USERNAME WITH ENCRYPTED PASSWORD 'PATRONI_REWIND_PASSWORD';
    GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO PATRONI_REWIND_USERNAME;
    GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO PATRONI_REWIND_USERNAME;
    GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO PATRONI_REWIND_USERNAME;
    GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO PATRONI_REWIND_USERNAME;

  2. Выполните следующие шаги на всех узлах PostgreSQL. Выполняйте все шаги на одном узле перед переходом к следующему узлу. Начните с основного узла, затем перейдите к каждому резервному узлу:

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

    2. Создайте файл конфигурации YAML для Patroni. Можно использовать инструменты генерации и проверки конфигурации Patroni для этого.

      Примечание (специфично для основного узла)

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

    3. Запустите Patroni с помощью блока службы patroni systemd. Он автоматически обнаружит, что PostgreSQL уже запущен, и начнет мониторинг экземпляра.

  3. Передайте процедуру запуска PostgreSQL в Patroni. Для этого перезапустите участников кластера через команду patronictl restart cluster-name member-name. Для минимального времени простоя можно разделить этот шаг на:

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

  4. Если были настроены постоянные слоты на шаге 1.2., то удалите их из конфигурации slots с помощью команды patronictl edit-config cluster-name member-name после того, как restart_lsn слотов, созданных Patroni, сможет догнать restart_lsn исходных слотов для соответствующих членов. Удаляя слоты из конфигурации slots позволяет Patroni удалить исходные соответствующие слоты из кластера, когда они больше не понадобятся. Ниже приведен пример запроса для проверки restart_lsn пары слотов, чтобы можно было сравнить их:

    -- Assume original_slot_for_member_x is the name of the slot in your original
    -- cluster for replicating changes to member X, and slot_for_member_x is the
    -- slot created by Patroni for that purpose. You need restart_lsn of
    -- slot_for_member_x to be >= restart_lsn of original_slot_for_member_x
    SELECT slot_name,
           restart_lsn
    FROM pg_replication_slots
    WHERE slot_name IN (
        'original_slot_for_member_x',
        'slot_for_member_x'
    )

Мажорное обновление версии PostgreSQL​

На данный момент единственный возможный способ выполнить мажорное обновление заключается в следующем:

  1. Остановите Patroni.
  2. Обновите бинарные файлы PostgreSQL и выполните pg_upgrade на основном узле.
  3. Обновить patroni.yml.
  4. Удалите ключ инициализации из DCS или полностью удалите состояние кластера из DCS. Второго можно достичь, запустив patronictl remove cluster-name. Это необходимо потому, что pg_upgrade запускает initdb, который фактически создает новую базу данных с новым системным идентификатором PostgreSQL.
  5. Если очистить состояние кластера на предыдущем шаге, скопировать patroni.dynamic.json из старого каталога данных в новый. Это поможет сохранить некоторые параметры PostgreSQL, которые были установлены ранее.
  6. Запустите Patroni на главном узле.
  7. Обновите бинарные файлы PostgreSQL, обновите файл patroni.yml и очистите каталог данных на узлах-резервных копиях.
  8. Запустите Patroni на узлах-резервных копиях и дождитесь завершения репликации.

Запуск pg_upgrade на узлах-резервных копиях не поддерживается PostgreSQL. Если знаете, что делаете, то можете попробовать процедуру rsync, описанную по адресу https://www.postgresql.org/docs/current/pgupgrade.html вместо очистки каталога данных на узлах-резервных копиях. Однако самым безопасным способом является позволить Patroni выполнить репликацию данных самостоятельно.

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

  • При запуске Patroni, Patroni жалуется, что он не может привязаться к порту PostgreSQL.

    Нужно проверить listen_addresses и port в postgresql.conf и postgresql.listen в patroni.yml. Не забывайте, что pg_hba.conf должен разрешать такой доступ.

  • После того, как попросили Patroni перезапустить узел, PostgreSQL отображает сообщение об ошибке could not open configuration file "/etc/postgresql/10/main/pg_hba.conf": No such file or directory.

    Это может означать разные вещи в зависимости от того, как происходит управление конфигурацией PostgreSQL. Если указали postgresql.config_dir, Patroni генерирует pg_hba.conf на основе настроек только в разделе bootstrap при создании новой кластерной системы. В этом сценарии PGDATA не был пустым, поэтому начальная загрузка не произошла. Этот файл должен существовать заранее.