Миграция метаданных ADB Control и ADBM при установке ADB ES
- Предварительные требования
- Шаг 1. Миграция метаданных, хранимых в PostgreSQL
- Шаг 2. Обновление кластеров ADB
- Шаг 3. Переименование внешних баз данных PostgreSQL
- Шаг 4. Подключение внешних баз данных PostgreSQL к ADB ES
- Шаг 5. Установка кластера ADB ES и агентов в ADB
- Шаг 6. Действия после установки ADB ES
- Шаг 7. Проверка результатов
Начиная с версии 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.
|
ВАЖНО
|
Предварительные требования
Имена внешних баз данных 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
|
ВАЖНО
|
-
В зависимости от того, какие целевые базы данных PostgreSQL планируется использовать в ADB ES, выполните следующее:
-
Внешние базы данных PostgreSQL: — выполните шаги 1 — 3 из раздела PostgreSQL статьи Настройка внешних баз данных для ADB Control и ADBM.
-
Внутренние базы данных ADPG, поставляемые в бандле ADB ES — добавьте сервис Database в кластер ADB ES (в одном экземпляре), выполните для него распределение компонентов и установку. Перед установкой на этапе конфигурирования сервиса в параметре Database type оставьте значение по умолчанию
Internal postgres database parameters.
-
-
Выполните миграцию метаданных из ранее использовавшихся внутренних баз данных в новые (внешние либо поставляемые с бандлом 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 используйте значения по умолчанию, перечисленные выше.
-
-
-
Выполните восстановление данных из каждого созданного дампа. Для этого на хосте, где развернуты целевые базы данных, запустите утилиту 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— исключение информации о владельцах объектов БД при восстановлении (владельцы будут установлены далее).
-
-
Убедитесь, что данные загружены в целевую БД. Для этого можно сравнить число строк в ключевых таблицах исходной и целевой БД:
SELECT count(*) FROM <schema>.<table>;Пример запроса для ADBM:
SELECT count(*) FROM adbm.adbm_restore_point; -
Проверьте, что у схем
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.
-
-
Для схемы
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 (до обновления):
-
Удалите сервис ADBM из кластера ADB, используя сервисное действие Uninstall. В поле Erase data установите
false. -
Удалите сервис ADB Control из кластера ADB, используя сервисное действие Uninstall. В поле Erase data установите
false. -
Выполните обновление кластера 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). |
-
Добавьте сервис Database в кластер ADB ES (в одном экземпляре) и выполните для него распределение компонентов.
-
На странице конфигурирования сервиса Database выберите
External postgres parametersв поле Database type и заполните параметры в открывшемся списке. Назначение параметров описано в разделе Конфигурационные параметры → Database → External postgres parameters.
Параметры для подключения к внешней БД PostgreSQL -
После заполнения параметров нажмите Save для сохранения конфигурации Database.
Шаг 5. Установка кластера ADB ES и агентов в ADB
-
В базе данных ADB Control, куда проведена миграция метаданных (внешней либо внутренней), выполните запрос для удаления данных о существующем кластере ADB (необходимо для предотвращения конфликтов в будущем):
DELETE FROM adcc.system_user WHERE cluster_name = '<cluster_name>';где
<cluster_name>— имя кластера ADB. -
В ADB ES добавьте оставшиеся сервисы (кроме Database) и выполните распределение их компонентов хостам.
-
Выполните установку ADB ES, применив кластерное действие Install.
-
Добавьте сервисы ADBC agents и ADBM agents во все кластеры ADB, мониторинг которых осуществлялся в ADB Control ранее (до обновления).
-
Импортируйте конфигурацию ADB ES в кластеры ADB.
-
Выполните установку сервисов ADBC agents и ADBM agents в кластерах ADB.
Шаг 6. Действия после установки ADB ES
-
В случае проблем с функционалом GUC в web-интерфейсе ADB Control после обновления — на стороне хоста, где развернут ADB Control UI, добавьте следующую запись в файл /etc/hosts:
<master_IP> <master_hostname>
Поскольку мастер-агент ADB Control регистрируется в Eureka с использованием имени мастер-хоста ADB, после обновления могут возникнуть проблемы при обращении ADB Control UI к агенту для управления GUC.
-
На мастер-хосте кластера ADB вызовите следующую команду для удаления всех существующих конфигурационных файлов утилиты pgbackrest:
$ gpssh -f arenadata_configs/arenadata_all_hosts.hosts -v -e 'rm -rf /home/gpadmin/arenadata_configs/pgbackrest/*' -
В интерфейсе сервиса ADBM (установленного в рамках кластера ADB ES) выполните действие Verify для пересоздания конфигурационных файлов.
-
В интерфейсе сервиса ADBM (установленного в рамках кластера ADB ES) выполните действие Create configuration для переприменения текущей конфигурации бэкапа.
Шаг 7. Проверка результатов
Если описанные выше шаги выполнены успешно, в web-интерфейсе ADB Control на странице Configuration → Clusters должны отобразиться все кластеры ADB, зарегистрированные для мониторинга в предыдущей версии ADB Control (до обновления).