Обновление кластера Greengage DB

Андрей Аксенов

Contents

Обзор
Подготовка к обновлению
Миграция данных
Завершение миграции

В этой статье описано, как обновить кластер Greengage DB на более новую версию.

Версия Greengage DB состоит из трех частей: <major>.<minor>.<patch> — например, 6.29.2 или 7.4.1:

major — увеличивается при изменениях системного каталога, несовместимых изменениях или добавлении значительных новых возможностей. Устаревшая функциональность может быть удалена в мажорном релизе.
minor — увеличивается при добавлении обратно совместимых возможностей или при объявлении функциональности устаревшей. Устаревшие возможности не удаляются в минорных релизах.
patch — увеличивается при обратно совместимых исправлениях ошибок внутри минорного релиза.

Минорные и патч-релизы не меняют внутренний формат хранения, поэтому они всегда совместимы с другими релизами той же старшей версии. Например, версия 6.29.2 совместима с 6.28.0, а 7.4.1 — с 7.2.0. Чтобы обновиться между совместимыми версиями, замените исполняемые файлы, пока кластер остановлен, а затем перезапустите его.

Внутренний формат хранения может измениться между мажорными версиями. Для обновления до новой мажорной версии выгрузите данные из старого кластера и восстановите их в новом с помощью утилит gpbackup и gprestore.

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

При планировании перехода на новую мажорную версию обратите внимание на изменения в следующих областях:

Администрирование: Возможности мониторинга и управления могут изменяться или быть расширены в мажорном релизе.
SQL: Изменения могут включать новые возможности SQL, расширения или модификации существующего поведения. Пример несовместимых изменений на уровне SQL см. в статье Несовместимости SQL между Greengage DB 6 и 7.
API библиотек: Для клиентских библиотек, таких как libpq, может вноситься новая функциональность или изменения. Совместимость обычно сохраняется, если не указано иное.
Системные каталоги: Изменения системного каталога влияют на внутреннюю структуру метаданных базы данных. Эти изменения могут повлиять на административные инструменты, системы мониторинга или пользовательские запросы, которые обращаются к таблицам каталога напрямую.
API сервера для кода на C: Изменения в API серверных функций, написанных на C, могут повлиять на расширения или интеграции, которые используют внутреннее API сервера.

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

Перед началом:

Проверьте несовместимые изменения.

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

Установите и инициализируйте новый кластер Greengage DB целевой версии.
Установите gpbackup и gprestore.

Утилиты должны быть установлены на хосте мастера/координатора обоих кластеров — старого и нового.

Следующие шаги описывают миграцию данных с использованием gpbackup и gprestore. Предполагается, что оба кластера имеют одинаковую структуру: один мастер/координатор и два сегмент-хоста, на каждом по два основных сегмента.

Запустите gpbackup на мастере/координаторе старого кластера, чтобы создать бэкап требуемой базы данных, например:

$ gpbackup \
  --dbname marketplace \
  --backup-dir /home/gpadmin \
  --single-backup-dir \
  --without-globals

--dbname указывает имя базы данных для бэкапа.
--backup-dir указывает каталог для сохранения файлов бэкапа.
--single-backup-dir сохраняет все файлы бэкапа для каждого хоста в одном каталоге вместо создания отдельных каталогов для каждого сегмента.
--without-globals исключает глобальные объекты, такие как роли, ресурсные группы и табличные пространства. Этот параметр может быть полезен, если между релизами есть несовместимые изменения в определениях глобальных объектов.

Когда бэкап успешно завершается, в выводе появляется следующее сообщение:

[INFO]:-Backup completed successfully

Также в выводе содержится метка времени бэкапа, которая однозначно идентифицирует его и используется для последующего восстановления:

[INFO]:-Backup Timestamp = 20260401143034

gpbackup записывает метаданные и конфигурационные файлы на мастер, а файлы данных — на каждый сегмент-хост. Перед продолжением проверьте, что все файлы были созданы.

Следующий пример показывает расположение файлов бэкапа для кластера с одним мастером и двумя сегмент-хостами, на каждом из которых размещены два основных сегмента:

Мастер

backups/
`-- 20260401
    `-- 20260401143034
        |-- gpbackup_20260401143034_config.yaml
        |-- gpbackup_20260401143034_metadata.sql
        |-- gpbackup_20260401143034_report
        `-- gpbackup_20260401143034_toc.yaml

Сегмент-хост 1

backups/
`-- 20260401
    `-- 20260401143034
        |-- gpbackup_0_20260401143034_16385.gz
        |-- gpbackup_0_20260401143034_16438.gz
        |-- gpbackup_0_20260401143034_16446.gz
        |-- gpbackup_1_20260401143034_16385.gz
        |-- gpbackup_1_20260401143034_16438.gz
        `-- gpbackup_1_20260401143034_16446.gz

Сегмент-хост 2

backups/
`-- 20260401
    `-- 20260401143034
        |-- gpbackup_2_20260401143034_16385.gz
        |-- gpbackup_2_20260401143034_16438.gz
        |-- gpbackup_2_20260401143034_16446.gz
        |-- gpbackup_3_20260401143034_16385.gz
        |-- gpbackup_3_20260401143034_16438.gz
        `-- gpbackup_3_20260401143034_16446.gz

Скопируйте каталоги backups на соответствующие хосты в новом кластере, сохранив структуру каталогов. На каждом хосте в новом кластере должны быть файлы бэкапа по тому же пути, который использует gpbackup — /home/gpadmin в данном примере.

При необходимости измените владельца файлов так, чтобы пользователь gpadmin имел к ним доступ:

$ sudo chown -R gpadmin:gpadmin /home/gpadmin/backups

На координаторе целевого кластера создайте базу данных с тем же именем, что и у исходной базы данных:

$ createdb marketplace

Запустите gprestore на координаторе нового кластера, используя временную метку, полученную на шаге 1:

$ gprestore \
  --backup-dir /home/gpadmin \
  --timestamp 20260401143034

--backup-dir указывает путь к каталогу, содержащему файлы бэкапа.

После успешного восстановления в выводе будет следующее сообщение:

[INFO]:-Restore completed successfully

Если вы пропустили какие-либо таблицы во время восстановления, перенесите их другими способами — например, экспортируйте их с помощью COPY TO и загрузите полученные файлы в новый кластер с помощью COPY FROM.

Воссоздайте все объекты, которые были удалены для выполнения миграции, такие как внешние таблицы, индексы и пользовательские функции.

После миграции данных при необходимости обновите SQL-скрипты, административные скрипты и пользовательские функции, чтобы учесть изменения в новой версии. Пример несовместимых изменений на уровне SQL см. в статье Несовместимости SQL между Greengage DB 6 и 7.

Управление spill-файлами

Несовместимости SQL между Greengage DB 6 и 7

Обновление кластера Greengage DB

Обзор

Подготовка к обновлению

Миграция данных

Шаг 1. Создание бэкапа исходной базы данных

Шаг 2. Проверка файлов бэкапа

Шаг 3. Копирование файлов бэкапа на новый кластер

Шаг 4. Создание целевой базы данных

Шаг 5. Восстановление данных в новом кластере

Завершение миграции