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

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

примечание

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

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

Чтобы развернуть кластер Patroni без использования существующего экземпляра PostgreSQL, смотрите вместо этого раздел Запуск и настройка.

Процедура​

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

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

    -- Суперпользователь Patroni
    -- Замените PATRONI_SUPERUSER_USERNAME и PATRONI_SUPERUSER_PASSWORD соответствующим образом
    CREATE USER PATRONI_SUPERUSER_USERNAME WITH SUPERUSER ENCRYPTED PASSWORD 'PATRONI_SUPERUSER_PASSWORD';

    -- Пользователь репликации Patroni
    -- Замените PATRONI_REPLICATION_USERNAME и PATRONI_REPLICATION_PASSWORD соответствующим образом
    CREATE USER PATRONI_REPLICATION_USERNAME WITH REPLICATION ENCRYPTED PASSWORD 'PATRONI_REPLICATION_PASSWORD';

    -- Пользователь rewind Patroni, если намерены включить use_pg_rewind в конфигурации Patroni
    -- Замените PATRONI_REWIND_USERNAME и PATRONI_REWIND_PASSWORD соответствующим образом
    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. Выполните следующие шаги на всех узлах Postgres. Выполните все шаги на одном узле, прежде чем переходить к следующему. Начните с первичного узла, затем перейдите к каждому standby-узлу:

    1. Если Postgres запускается через systemd, отключите systemd-юнит Postgres. Это делается потому, что Patroni управляет запуском и остановкой демона Postgres.

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

      примечание

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

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

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

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

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

    -- Предположим, original_slot_for_member_x — это имя слота в исходном
    -- кластере для репликации изменений на участник X, а slot_for_member_x — это
    -- слот, созданный Patroni для этой цели. Необходимо, чтобы restart_lsn
    -- slot_for_member_x был >= restart_lsn 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. Удалить ключ initialize из DCS или полностью очистить состояние кластера из DCS. Второе можно достичь, выполнив команду patronictl remove cluster-name. Это необходимо, потому что pg_upgrade запускает initdb, который фактически создает новую базу данных с новым системным идентификатором PostgreSQL.
  5. Если было очищено состояние кластера на предыдущем шаге, можно скопировать patroni.dynamic.json из старого каталога данных в новый. Это поможет сохранить некоторые параметры PostgreSQL, которые были установлены ранее.
  6. Запустить Patroni на первичном узле.
  7. Обновить бинарные файлы PostgreSQL, обновить patroni.yml и очистить data_dir на standby-узлах.
  8. Запустить Patroni на standby-узлах и дождаться завершения репликации.

Запуск pg_upgrade на standby-узлах не поддерживается PostgreSQL. Если требуется выполнить процедуру rsync, описанную в документации, вместо очистки data_dir на standby-узлах, это можно попробовать на свой страх и риск. Однако самый безопасный способ — позволить 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 не был пустым, поэтому бутстрап не произошел. Этот файл должен существовать заранее.