Миграция метаданных ADB Control и ADBM при установке ADB ES

Начиная с версии ADB 6.30.0.1 сервисы ADB Control и ADBM поставляются в отдельном бандле ADB Enterprise Services (ADB ES). На стороне ADB устанавливаются только агенты: ADBM agents и ADBC agents. Ниже приведены шаги, которые следует выполнить при исходной установке кластера ADB ES для корректного обновления ADB (до версии 6.30.0.1), включая миграцию метаданных ADB Control и ADBM из ADB в ADB ES.

ВАЖНО
  • Описанные ниже действия следует выполнить однократно при первоначальной установке ADB ES и обновлении ADB до версии 6.30.0.1 в случае, если в ADB ранее использовался сервис ADB Control или ADBM. При отсутствии этих сервисов в кластере ADB необходимости в описанных ниже шагах нет, вместо этого следует выполнить стандартное обновление кластера ADB и offline-установку кластера ADB ES (после чего добавить агенты ADBC и ADBM в ADB, выполнить импорт настроек ADB ES в ADB и установить агенты в ADB).

  • Минимальная версия ADB для обновления — 6.27.1.63.

Предварительные требования

Имена внешних баз данных PostgreSQL, используемых для сервисов ADB Control и ADBM в кластере ADB ES (независимо от того, были ли они добавлены ранее или будут созданы при выполнении шагов ниже), должны формироваться по следующему шаблону:

  • ADB Control — <prefix>_adcc

  • ADBM — <prefix>_adbm

Префикс <prefix> должен быть одинаковым для обоих сервисов, впоследствии он указывается в настройках сервиса Database в параметре External postgres parameters → Database name prefix. Примеры корректных имен баз данных: external_adcc и external_adbm (где external — префикс).

Если внешние базы данных уже были созданы ранее с именами, не удовлетворяющими указанным выше, необходимо выполнить их переименование после обновления ADB до установки ADB ES (см. Шаг 3. Переименование внешних баз данных PostgreSQL).

Шаг 1. Миграция метаданных, хранимых в PostgreSQL

ВАЖНО
  • Шаг 1 следует выполнять только в случае, если в ADB для сервисов ADB Control или ADBM не использовалась внешняя база данных PostgreSQL. Если внешняя база использовалась для обоих сервисов, необходимо перейти к следующему шагу без выполнения миграции. Если внешняя база данных не использовалась для одного из сервисов — шаг 1 выполняется только для него.

  • Так как в кластере ADB ES предусмотрен один общий сервис Database для ADB Control и ADBM — в случае, если ранее для хранения внешних БД этих сервисов использовались разные серверы PostgreSQL, необходимо выбрать один из них, перенести на него обе внешние БД, и впоследствии указать его настройки в сервисе Database кластера ADB ES. Владельцем обеих БД должен быть один пользователь.

  1. В зависимости от того, какие целевые базы данных PostgreSQL планируется использовать в ADB ES, выполните следующее:

  2. Выполните миграцию метаданных из ранее использовавшихся внутренних баз данных в новые (внешние либо поставляемые с бандлом ADBES). Для этого на хосте, где развернуты целевые базы данных, можно воспользоваться утилитой pg_dump. Пример вызова утилиты:

    $ sudo -u postgres pg_dump -h <host> -p <port> --format=custom --no-owner --no-privileges -U <user> -f /tmp/<dump>.dump <database_name>

    где:

    • -h <host> — IP-адрес хоста, на котором развернута внутренняя база данных, из которой осуществляется миграция.

    • -p <port> — номер порта для подключения к внутренней базе данных (по умолчанию 5433).

    • --format=custom — создание сжатого дампа, подходящего для восстановления утилитой pg_restore.

    • --no-owner — исключение информации о владельцах объектов БД при создании дампа (владельцы будут установлены на этапе восстановления данных).

    • --no-privileges — исключение информации о привилегиях (при необходимости эта информация может быть восстановлена отдельно).

    • -U <user> — имя пользователя для подключения к внутренней базе данных (по умолчанию postgres).

    • -f /tmp/<dump>.dump — путь к создаваемому дампу данных. Замените <dump> именем файла.

    • <database_name> — имя внутренней базы данных (по умолчанию adbm для ADBM и adcc для ADB Control).

      ВАЖНО
      • Для сервисов ADB Control и ADBM необходимо создавать отдельные дампы, так как их данные хранятся в разных БД.

      • При вызове утилиты будет запрошен пароль пользователя для подключения к внутренней базе данных. Значение по умолчанию — 123 (однако в вашем окружении пароль может быть иным — см. примечание ниже).

      • В примере вызова утилиты приведены учетные данные, используемые по умолчанию. Однако для ADB Control их следует заменить на те, что вы указывали при конфигурировании этого сервиса в кластере ADB (см. ADB Control → Database parameters в версиях документации ADB, предшествующих 6.30.0). Для ADBM используйте значения по умолчанию, перечисленные выше.

  3. Выполните восстановление данных из каждого созданного дампа. Для этого на хосте, где развернуты целевые базы данных, запустите утилиту pg_restore:

    $ sudo -u postgres pg_restore -p <target_port> -d <target_db> --clean --no-owner /tmp/<dump>.dump

    где:

    • -p <target_port> — номер для подключения к целевой базе данных, в которую осуществляется миграция. В случае использования БД, поставляемой с бандлом ADB ES, номер порта — 5433.

    • -d <target_db> — название целевой базы данных, в которую осуществляется миграция. В случае использования БД, поставляемой с бандлом ADB ES, имя БД — adcc для ADB Control и adbm для ADBM.

    • --clean — удаление информации о существующих объектах БД перед восстановлением.

    • --no-owner — исключение информации о владельцах объектов БД при восстановлении (владельцы будут установлены далее).

  4. Убедитесь, что данные загружены в целевую БД. Для этого можно сравнить число строк в ключевых таблицах исходной и целевой БД:

    SELECT count(*) FROM <schema>.<table>;

    Пример запроса для ADBM:

    SELECT count(*) FROM adbm.adbm_restore_point;
  5. Проверьте, что у схем adcc и adbm в целевых базах данных установлен корректный владелец. При необходимости измените его. Пример команды для схемы adbm:

    $ sudo -u postgres psql -p <target_port> -d <target_db> -c "ALTER SCHEMA adbm OWNER TO <target_owner>;"

    где <target_owner>:

    • В случае использования внешних БД — значение <user_name>, которое вы использовали при выполнении SQL-команд из статьи Настройка внешних баз данных для ADB Control и ADBM.

    • В случае использования БД, поставляемых в бандле ADB ES — postgres.

  6. Для схемы quartz в ADBM необходимо восстановить данные о владельцах таблиц и последовательностей, используя следующие запросы (в случае потери привилегий в ходе миграции).

    Для таблиц:

    DO $$ DECLARE r record;
    BEGIN
        FOR r IN SELECT tablename FROM pg_tables WHERE schemaname = 'quartz' LOOP
            EXECUTE 'ALTER TABLE quartz.' || quote_ident(r.tablename) || ' OWNER TO <target_owner>;';
        END LOOP;
    END $$;

    Для последовательностей:

    DO $$ DECLARE r record;
    BEGIN
        FOR r IN SELECT sequence_name FROM information_schema.sequences WHERE sequence_schema = 'quartz' LOOP
            EXECUTE 'ALTER SEQUENCE quartz.' || quote_ident(r.sequence_name) || ' OWNER TO <target_owner>;';
        END LOOP;
    END $$;

    где описание <target_owner> можно взять из предыдущего шага.

Шаг 2. Обновление кластеров ADB

Для каждого кластера ADB, зарегистрированного для мониторинга в предыдущей версии ADB Control (до обновления):

  1. Удалите сервис ADBM из кластера ADB, используя сервисное действие Uninstall. В поле Erase data установите false.

  2. Удалите сервис ADB Control из кластера ADB, используя сервисное действие Uninstall. В поле Erase data установите false.

  3. Выполните обновление кластера ADB до версии 6.30.0.1.

Шаг 3. Переименование внешних баз данных PostgreSQL

Если внешние базы данных уже были созданы ранее с именами, не удовлетворяющими указанным выше шаблонам, их необходимо переименовать до выполнения последующих шагов. Однако переименование изменяет контрольные суммы Liquibase, что может негативно сказаться на дальнейших обновлениях. Во избежание этого после переименования выполните следующую команду в каждой внешней БД PostgreSQL (для ADB Control и ADBM):

UPDATE DATABASECHANGELOG SET MD5SUM = NULL;

Шаг 4. Подключение внешних баз данных PostgreSQL к ADB ES

ВАЖНО

Приведенные на шаге 4 действия следует выполнять только в случае, если вы планируете использовать внешний PostgreSQL (не поставляемый в бандле ADB ES).

  1. Добавьте сервис Database в кластер ADB ES (в одном экземпляре) и выполните для него распределение компонентов.

  2. На странице конфигурирования сервиса Database выберите External postgres parameters в поле Database type и заполните параметры в открывшемся списке. Назначение параметров описано в разделе Конфигурационные параметры → Database → External postgres parameters.

    Параметры для подключения к внешней БД PostgreSQL
    Параметры для подключения к внешней БД PostgreSQL
  3. После заполнения параметров нажмите Save для сохранения конфигурации Database.

Шаг 5. Установка кластера ADB ES и агентов в ADB

  1. В базе данных ADB Control, куда проведена миграция метаданных (внешней либо внутренней), выполните запрос для удаления данных о существующем кластере ADB (необходимо для предотвращения конфликтов в будущем):

    DELETE FROM adcc.system_user WHERE cluster_name = '<cluster_name>';

    где <cluster_name> — имя кластера ADB.

  2. В ADB ES добавьте оставшиеся сервисы (кроме Database) и выполните распределение их компонентов хостам.

  3. Выполните установку ADB ES, применив кластерное действие Install.

  4. Добавьте сервисы ADBC agents и ADBM agents во все кластеры ADB, мониторинг которых осуществлялся в ADB Control ранее (до обновления).

  5. Импортируйте конфигурацию ADB ES в кластеры ADB.

  6. Выполните установку сервисов ADBC agents и ADBM agents в кластерах ADB.

Шаг 6. Действия после установки ADB ES

  1. В случае проблем с функционалом GUC в web-интерфейсе ADB Control после обновления — на стороне хоста, где развернут ADB Control UI, добавьте следующую запись в файл /etc/hosts:

    <master_IP> <master_hostname>

    Поскольку мастер-агент ADB Control регистрируется в Eureka с использованием имени мастер-хоста ADB, после обновления могут возникнуть проблемы при обращении ADB Control UI к агенту для управления GUC.

  2. На мастер-хосте кластера ADB вызовите следующую команду для удаления всех существующих конфигурационных файлов утилиты pgbackrest:

    $ gpssh -f arenadata_configs/arenadata_all_hosts.hosts -v -e 'rm -rf /home/gpadmin/arenadata_configs/pgbackrest/*'
  3. В интерфейсе сервиса ADBM (установленного в рамках кластера ADB ES) выполните действие Verify для пересоздания конфигурационных файлов.

  4. В интерфейсе сервиса ADBM (установленного в рамках кластера ADB ES) выполните действие Create configuration для переприменения текущей конфигурации бэкапа.

Шаг 7. Проверка результатов

Если описанные выше шаги выполнены успешно, в web-интерфейсе ADB Control на странице Configuration → Clusters должны отобразиться все кластеры ADB, зарегистрированные для мониторинга в предыдущей версии ADB Control (до обновления).

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней