GitHub

Расширение кластера

Павел Семёнов

Этот раздел описывает, как расширить кластер Greengage DB (на основе Greenplum) путем добавления новых сегментов и хостов.

По мере роста объема хранимых данных может появляться необходимость увеличения дискового пространства. В других случаях необходимо увеличение вычислительной мощности для эффективной обработки аналитических запросов. Заранее предсказать будущие потребности в ресурсах для хранения и обработки данных бывает сложно, особенно при работе с большими данными.

СУБД Greengage решает эти задачи, обеспечивая линейную масштабируемость. Вы можете расширить существующий кластер, добавив новые сегмент-хосты, тем самым увеличивая как объем хранения, так и вычислительные мощности. После расширения кластер функционирует так, как если бы он изначально был создан с новой конфигурацией. Это позволяет в дальнейшем продолжать расширение кластера по мере роста объема данных.

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

Проверка требований

Перед расширением кластера Greengage DB подготовьте новые сегмент-хосты и убедитесь, что они соответствуют необходимым требованиям. Эти хосты могут быть как физическими серверами, так и облачными ресурсами в зависимости от среды развертывания.

Количество новых хостов должно быть достаточным для применения политики зеркалирования, используемой в кластере — grouped или spread. Для политики зеркалирования grouped требуется минимум два дополнительных хоста, так как каждый хост хранит зеркала основных сегментов другого хоста.

Аппаратные, программные и сетевые конфигурации новых хостов должны соответствовать параметрам существующих сегмент-хостов. Узнайте подробнее о программных и сетевых требованиях к Greengage DB.

Настройка новых хостов

Перед добавлением новых хостов в кластер настройте их операционные системы и установите СУБД Greengage, как описано в этом разделе.

Установка Greengage DB

Подготовьте новые хосты для работы Greengage DB:

  1. Установите все необходимые программные зависимости, перечисленные в этом разделе: Требования к ПО для установки Greengage DB.

  2. Установите Greengage DB на все хосты. Например, чтобы установить Greengage DB, собранный из исходного кода, выполните действия, описанные в разделе: Сборка Greengage DB из исходного кода. В этом разделе описано, как:

    • настроить операционную систему;

    • создать административного пользователя Greengage DB;

    • собрать Greengage DB из исходного кода;

    • установить Greengage DB.

      ПРИМЕЧАНИЕ

      Для инициализации СУБД вам не нужно создавать тестовый кластер.

Если ваш кластер использует расширения, такие как PXF, MADlib или PostGIS, вам также нужно установить их зависимости на новые хосты.

Настройка разрешения имен хостов

Убедитесь, что разрешение имен согласовано для всех хостов, существующих и новых. Если вы используете ручную настройку разрешения имен в файле /etc/hosts, обновите его на каждом хосте, добавив имена новых хостов.

Например, если вы добавляете хосты sdw3 и sdw4 в кластер с четырьмя хостами mdw, smdw, sdw1 и sdw2, файл должен выглядеть следующим образом на всех хостах:

# ...
192.168.1.10 mdw
192.168.1.20 smdw
192.168.1.30 sdw1
192.168.1.40 sdw2
192.168.1.50 sdw3
192.168.1.60 sdw4

Создание файла с новыми хостами

  1. Подключитесь к мастер-хосту под пользователем gpadmin и войдите в домашний каталог.

  2. Создайте файл hostfile_new_hosts:

    $ vi hostfile_new_hosts

  3. Добавьте в этот файл имена новых сегмент-хостов:

    sdw3
sdw4

  4. Сохраните и закройте файл.

Настройка беспарольного SSH для новых хостов

Выполните следующие команды на мастер-хосте:

  1. Включите беспарольный SSH-доступ с мастер-хоста на новые хосты. Используйте ssh-copy-id, чтобы скопировать открытый ключ пользователя gpadmin в файл authorized_keys на новых хостах:

    $ ssh-copy-id sdw3
$ ssh-copy-id sdw4

  2. Настройте беспарольный SSH-доступ между всеми хостами будущего кластера с помощью утилиты gpssh-exkeys:

    $ gpssh-exkeys -e <hostfile_all_hosts> -x hostfile_new_hosts

    где <hostfile_all_hosts> — это список хостов исходного кластера, который использовался для его инициализации.

Создание каталогов данных

Создайте каталоги данных на новых хостах с помощью утилиты gpssh:

$ gpssh -f hostfile_new_hosts -e 'sudo mkdir -p /data1/primary'
$ gpssh -f hostfile_new_hosts -e 'sudo mkdir -p /data1/mirror'
$ gpssh -f hostfile_new_hosts -e 'sudo chown -R gpadmin /data1/*'
ВАЖНО

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

Тестирование производительности

После настройки новых хостов рекомендуется проверить производительность их дисковой системы с помощью утилиты gpcheckperf:

$ gpcheckperf -f hostfile_new_hosts -d /data1/primary -d /data1/mirror

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

Если это возможно в вашей среде, остановите кластер и проверьте производительность будущего расширенного кластера целиком:

$ gpstop -a
$ gpcheckperf -f <hostfile_all_with_new> -d /data1/primary -d /data1/mirror

где <hostfile_all_with_new> — файл со списком всех хостов будущего кластера: существующих и новых.

Инициализация новых сегментов

ВНИМАНИЕ

Рекомендуется создать резервную копию исходного кластера с помощью утилиты gpbackup до начала процесса расширения.

Файл конфигурации новых сегментов

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

Для интерактивной генерации файла конфигурации сегментов:

  1. Запустите gpexpand, указав файл с новыми хостами в опции -f:

    $ gpexpand -f hostfile_new_hosts
    ПРИМЕЧАНИЕ

    Вы также можете запустить gpexpand без аргументов. В этом случае утилита предложит ввести новые имена хостов интерактивно.

  2. Введите y, чтобы подтвердить расширение кластера, и нажмите Enter:

    Would you like to initiate a new System Expansion Yy|Nn (default=N):

  3. (Опционально) Если при вызове gpexpand не был указан хост-файл, введите имена новых хостов через запятую:

    Enter a comma separated list of new hosts you want
to add to your array.  Do not include interface hostnames.
**Enter a blank line to only add segments to existing hosts**[]:

  4. Определите стратегию зеркалирования в расширенном кластере: grouped (по умолчанию) или spread.

    What type of mirroring strategy would you like?
spread|grouped (default=grouped):

  5. Введите количество новых основных сегментов, добавляемых на каждый существующий хост:

    How many new primary segments per host do you want to add? (default=0):

    Чтобы оставить существующие сегмент-хосты без изменений и создать такое же количество новых сегментов на новых хостах, введите 0 или нажмите Enter.

    ВАЖНО

    Это число определяет, сколько новых основных сегментов будет создано дополнительно к уже существующим на сегмент-хостах. На новых хостах будет создано столько же основных сегментов, сколько будет на существующих хостах после расширения.

    Например, если в кластере два сегмент-хоста sdw1 и sdw2 хранят по два основных сегмента, ввод 1 приведет к следующей конфигурации:

    • Существующие хосты sdw1 и sdw2 будут хранить по три основных сегмента: два старых и один новый.

    • Все новые хосты получат по три новых основных сегмента.

    • Всего в кластере будет 12 основных сегментов.

  6. (Опционально) Если расширение подразумевает создание новых сегментов на существующих хостах, укажите каталоги для хранения их данных: основных и зеркальных.

Утилита выводит имя созданного файла конфигурации сегментов в сообщении вида:

Input configuration file was written to 'gpexpand_inputfile_20250312_083443'.

Этот файл расширяет кластер, добавляя по два новых основных сегмента на каждом новом хосте (sdw3 и sdw4). Хосты хранят зеркала основных сегментов друг друга.

sdw3|sdw3|10000|/data1/primary/gpseg4|11|4|p
sdw4|sdw4|10500|/data1/mirror/gpseg4|17|4|m
sdw3|sdw3|10001|/data1/primary/gpseg5|12|5|p
sdw4|sdw4|10501|/data1/mirror/gpseg5|18|5|m
sdw4|sdw4|10000|/data1/primary/gpseg6|13|6|p
sdw3|sdw3|10500|/data1/mirror/gpseg6|15|6|m
sdw4|sdw4|10001|/data1/primary/gpseg7|14|7|p
sdw3|sdw3|10501|/data1/mirror/gpseg7|16|7|m

Файл конфигурации сегментов состоит из строк следующей структуры:

hostname|address|port|datadir|dbid|content|preferred_role
Структура файла конфигурации сегментов
Поле Описание

hostname

Имя хоста

address

Адрес хоста. Может совпадать со значением hostname в системах, не использующих настройку имен хостов для каждого интерфейса (per-interface)

port

TCP-порт, прослушиваемый сегментом БД

datadir

Физическое расположение каталога данных сегмента

dbid

Уникальный идентификатор инстанса в кластере

content

Уникальный идентификатор сегмента данных

preferred_role

Роль, назначенная сегменту при инициализации системы. Возможные значения: p (primary — основной ) и m (mirror — зеркало)
ПРИМЕЧАНИЕ

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

Создание новых сегментов

ВНИМАНИЕ

Выполнение DDL-операций во время инициализации сегментов может привести к несогласованности кластера. Убедитесь, что DDL-операции не выполняются до завершения инициализации.

Чтобы создать новые сегменты на основе файла конфигурации, выполните команду gpexpand -i:

$ gpexpand -i <gpexpand_inputfile>

где <gpexpand_inputfile> — это файл конфигурации сегментов, созданный на предыдущем этапе.

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

[INFO]:-************************************************
[INFO]:-Initialization of the system expansion complete.
[INFO]:-To begin table expansion onto the new segments
[INFO]:-rerun gpexpand
[INFO]:-************************************************
[INFO]:-Exiting...

В результате выполнения команды:

  • Кластер переходит в состояние расширения. Теперь можно отслеживать процесс расширения с помощью gpstate -x:

    $ gpstate -x

    Команда выводит информацию о состоянии процесса расширения:

    [INFO]:-Cluster Expansion State = Data Distribution - Paused
[INFO]:-----------------------------------------------------
[INFO]:-Number of tables to be redistributed
[INFO]:-     Database   Count of Tables to redistribute
[INFO]:-     postgres   4
[INFO]:-----------------------------------------------------

  • В базе данных postgres на мастер-сегменте создается схема gpexpand. Эта схема хранит информацию о процессе расширения, позволяя отслеживать его прохождение.

    Таблицы схемы gpexpand
    Таблица Описание

    expansion_progress

    Общая информация о перераспределении данных во время расширения

    status

    Завершенные этапы расширения с отметками времени

    status_detail

    Подробный статус перераспределения данных каждой таблицы

  • Новые сегменты создаются на новых и существующих хостах в соответствии с указанной конфигурацией. Обновленная конфигурация сегментов сохраняется в системной таблице gp_segment_configuration. Новые сегменты создаются пустыми, а хранимые данные остаются в исходных сегментах. Чтобы сбалансировать данные, выполните перераспределение данных по всем сегментам расширенного кластера.

Откат

Если создание сегментов завершилось с ошибкой, восстановите исходную конфигурацию кластера с помощью gpexpand с опцией -r/--rollback:

$ gpexpand -r

Перераспределение данных таблиц

После добавления новых сегментов все данные остаются на существующих сегментах. Это приводит к дисбалансу в кластере, из-за которого основная нагрузка ложится на старые сегменты. Политика распределения всех распределенных таблиц меняется на DISTRIBUTED RANDOMLY, что может ухудшить их производительность. Чтобы сбалансировать нагрузку, данные необходимо перераспределить между всеми сегментами новой топологии. Когда перераспределение таблицы завершено, она возвращается к своей исходной политике распределения и оптимальной производительности.

Greengage DB предоставляет встроенный механизм перераспределения, который обеспечивает оптимальное распределение данных с минимальным влиянием на работу сервиса. Перераспределение можно выполнять только в рабочем (production) режиме кластера. В крупных кластерах этот процесс может потребовать значительных ресурсов и времени. Чтобы уменьшить влияние на производительность, Greengage DB позволяет приостанавливать и возобновлять процесс, разбивая его на несколько сессий ограниченной длительности. Прогресс перераспределения сохраняется в таблицах схемы gpexpand.

РЕКОМЕНДАЦИЯ

Запускайте сеансы перераспределения в периоды с низкой нагрузкой, чтобы минимизировать влияние на производительность.

Новые таблицы, созданные на этом этапе, автоматически распределяются по всем сегментам и не требуют перераспределения. Они доступны сразу после создания. Однако существующие таблицы временно блокируются для чтения и записи на время их перераспределения.

Порядок перераспределения таблиц

Чтобы минимизировать влияние на производительность запросов во время перераспределения, первыми рекомендуется перераспределить крупные и часто запрашиваемые таблицы. Это позволит быстрее сделать их доступными для работы в обычном режиме.

Порядок перераспределения определяется значением столбца rank в системной таблице gpexpand.status_detail. Меньшие значения имеют более высокий приоритет. Чтобы задать порядок перераспределения таблиц:

  1. Подключитесь к базе данных postgres на мастер-узле:

    $ psql postgres

  2. Установите большое значение rank для всех таблиц, например, 100:

    UPDATE gpexpand.status_detail SET rank = 100;

  3. Уменьшите значение rank для таблиц, которые нужно перераспределить в первую очередь:

    UPDATE gpexpand.status_detail SET rank = 10 WHERE fq_name = 'public.table3';
UPDATE gpexpand.status_detail SET rank = 20 WHERE fq_name = 'public.table2';
UPDATE gpexpand.status_detail SET rank = 30 WHERE fq_name = 'public.table4';

    Укажите название базы данных, если имена схем и таблиц повторяются:

    UPDATE gpexpand.status_detail SET rank = 50
                              WHERE fq_name = 'public.table4' AND dbname = 'test_db';
    РЕКОМЕНДАЦИЯ

    Использование круглых значений (10, 20, 30) увеличивает гибкость подстройки. При необходимости вы сможете изменить порядок перераспределения, обновив всего одну строку:

    UPDATE gpexpand.status_detail SET rank = 15 WHERE fq_name = 'public.table5';

Чтобы не выполнять перераспределение таблицы, удалите ее запись из таблицы gpexpand.status_detail:

DELETE FROM gpexpand.status_detail WHERE fq_name = 'public.table4';

Запуск сеансов перераспределения

Запустить перераспределение можно с помощью gpexpand, указав один из параметров:

  • -d <HH:MM:SS> — выполнять перераспределение в течение заданного периода времени.

  • -e <YYYY-MM-DD HH:MM:SS> — выполнять перераспределение до указанного момента времени.

Примеры:

  • Запустить сеанс перераспределения длительностью пять минут:

    $ gpexpand -d 00:05:00

  • Выполнять перераспределение до 9:00 13 марта 2025 года:

    $ gpexpand -e 2025-03-13 09:00:00

Greengage DB может выполнять перераспределение нескольких таблиц параллельно. Чтобы запустить параллельное перераспределение, укажите число таблиц для одновременной обработки в опции -n:

$ gpexpand -n 16
ВАЖНО

Во время перераспределения создается по два подключения на каждую таблицу: одно изменяет таблицу, а другое записывает прогресс в схему gpexpand. При задании числа таблиц для параллельного перераспределения убедитесь, что это не приведет к превышению максимального числа подключений к кластеру (параметр конфигурации max_connections). При необходимости увеличьте лимит подключений.

Мониторинг процесса расширения

В этом разделе описано, как отслеживать процесс расширения кластера.

Утилита gpstate

При вызове с флагом -x утилита gpstate показывает количество таблиц, которые еще не перераспределены:

$ gpstate -x

В выводе содержатся строки следующего вида:

[INFO]:-Cluster Expansion State = Data Distribution - Paused
[INFO]:-----------------------------------------------------
[INFO]:-Number of tables to be redistributed
[INFO]:-     Database   Count of Tables to redistribute
[INFO]:-     postgres   3
[INFO]:-----------------------------------------------------

Таблица gpexpand.expansion_progress

Таблица gpexpand.expansion_progress хранит текущую статистику процесса расширения, включая количество перераспределенных и оставшихся таблиц, объем переданных данных и предполагаемое время завершения.

SELECT * FROM gpexpand.expansion_progress;

Результат запроса:

             name             |         value
------------------------------+-----------------------
 Tables Expanded              | 1
 Estimated Expansion Rate     | 27.0714856745503 MB/s
 Bytes Left                   | 211241312
 Estimated Time to Completion | 00:00:07.441609
 Tables Left                  | 3
 Bytes Done                   | 264568832
(6 rows)

Таблица gpexpand.status_detail

Таблица gpexpand.status_detail хранит подробную информацию о процессе перераспределения для каждой таблицы.

SELECT dbname, fq_name,rank, status, expansion_started, expansion_finished
FROM gpexpand.status_detail;

Результат запроса:

  dbname  |    fq_name    | rank |   status    |     expansion_started      |     expansion_finished
----------+---------------+------+-------------+----------------------------+----------------------------
 postgres | public.table1 |  100 | NOT STARTED |                            |
 postgres | public.table4 |   30 | NOT STARTED |                            |
 postgres | public.table2 |   20 | NOT STARTED |                            |
 postgres | public.table3 |   10 | COMPLETED   | 2025-03-13 10:15:41.775582 | 2025-03-13 10:15:50.095813
(4 rows)

Дальнейшие шаги после расширения

Когда перераспределение всех таблиц завершено, в выводе gpexpand появляется строка:

[INFO]:-EXPANSION COMPLETED SUCCESSFULLY

Кроме того, в таблице gpexpand.status создается строка EXPANSION COMPLETE, подтверждающая завершение процесса:

SELECT * FROM gpexpand.status WHERE status = 'EXPANSION COMPLETE';

Результат запроса:

       status       |          updated
--------------------+----------------------------
 EXPANSION COMPLETE | 2025-03-13 10:29:18.385153
(1 row)

В этом разделе описаны шаги, выполнение которых может потребоваться после расширения кластера.

Удаление схемы расширения

После завершения перераспределения данных схема gpexpand больше не нужна. Удалите ее, выполнив следующую команду на мастер-узле:

$ gpexpand -c
ПРИМЕЧАНИЕ

Пока в кластере существует схема gpexpand, запуск нового процесса расширения невозможен.

Восстановление из резервной копии исходного кластера

Если вам потребуется восстановить данные из исходной копии, созданной до расширения кластера, используйте gprestore с опцией --resize-cluster.

$ gprestore --resize-cluster --backup-dir /data1/backup --timestamp 20250302111439

Настройка PXF

Если ваш кластер использует PXF, настройте его на всех узлах расширенного кластера:

  1. Установите PXF на новые хосты.

  2. Синхронизируйте конфигурацию PXF на всех узлах кластера:

    $ pxf cluster register
$ pxf cluster sync

  3. Перезапустите PXF:

    $ pxf cluster restart
Предыдущая
Запуск и остановка
Следующая
Настройка зеркалирования
Открыть страницу поиска