Ребалансировка и изменение размера кластера

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

Contents

Обзор
Предварительные требования
Просмотр плана ребалансировки
Возврат кластера в сбалансированное состояние
Изменение количества сегментов
- Уменьшение
Изменение набора сегмент-хостов
Изменение политики зеркалирования
Комбинированные изменения топологии
Настройка процесса ребалансировки
Мониторинг состояния ребалансировки
- Схема ggrebalance
- Лог-файлы утилиты ggrebalance
Дальнейшие шаги после ребалансировки
- Удаление схемы ребалансировки
- Сбор статистики
Откат ребалансировки

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

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

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

Добавление сегмент-хостов для увеличения емкости хранения.
Уменьшение количества сегментов в кластере с низкой нагрузкой.
Удаление неиспользуемых хостов после уменьшения размера кластера.
Замену хостов при миграции оборудования.

Такие операции требуют перераспределения сегментов по хостам и таблиц по сегментам для сохранения баланса в новой топологии.

Greengage DB позволяет изменять топологию существующего кластера, сохраняя его сбалансированное состояние. Вы можете изменить:

физическую топологию — набор сегмент-хостов, используемых кластером;
логическую топологию — количество сегментов в кластере.

Начиная с версии 7, Greengage DB включает утилиту ggrebalance для выполнения таких операций.

В данном разделе под сбалансированным кластером подразумевается состояние, когда:

Каждый сегмент-хост содержит одинаковое количество основных сегментов.
Зеркальные сегменты распределены в соответствии с выбранной политикой зеркалирования (grouped или spread).
Ни один основной сегмент не расположен на одном хосте со своим зеркалом.

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

Утилита ggrebalance выполняет сложные изменения топологии кластера, сохраняя сбалансированное распределение сегментов и минимизируя простой.

Для изменения топологии кластера ggrebalance создает и выполняет план ребалансировки на основе требуемой целевой топологии. Она задается параметрами вызова утилиты, такими как:

целевое количество сегментов (обязательно для всех вызовов ggrebalance, запускающих новую операцию);
целевые сегмент-хосты;
политика зеркалирования.

Используя эту информацию, ggrebalance определяет, как необходимо перераспределить данные таблиц и какие сегменты нужно переместить на другие хосты.

В отличие от gpexpand, ggrebalance автоматически планирует размещение сегментов; от администратора не требуется задавать сопоставление между сегментами и хостами вручную.

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

Утилита хранит состояние выполнения операции и является реентерабельной. Информация о ходе выполнения и метаданные хранятся в служебной схеме ggrebalance в базе данных postgres. Это позволяет прерывать операции и возобновлять их позже. В зависимости от стадии выполнения ggrebalance также может автоматически откатывать прерванные операции, возвращая кластер в исходное состояние.

На некоторых этапах ребалансировки возможно временное снижение доступности кластера. Например, пока перемещается зеркальный сегмент, для соответствующего основного сегмента не обеспечивается высокая доступность. Для перемещения основного сегмента (что нельзя сделать напрямую), ggrebalance выполняет переключение (switchover) — смену ролей, во время которой основной сегмент останавливается и перезапускается в роли зеркала. Так как при переключениях задействованные сегменты временно недоступны, ggrebalance требует явного подтверждения каждого из них, если не включено автоматическое подтверждение.

ВАЖНО

В версии 1.0 ggrebalance не поддерживает расширение кластера. Чтобы увеличить количество сегментов, используйте утилиту gpexpand.

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

Более подробно детали реализации утилиты описаны в блоге Greengage DB в посте: Shrink кластера и Iceberg-коннектор. Что нового?.

ggrebalance поддерживает следующие операции изменения топологии кластера:

Возврат несбалансированного кластера в сбалансированное состояние.
Изменение количества сегментов (уменьшение кластера).
Добавление сегмент-хостов.
Удаление сегмент-хостов.
Замена сегмент-хостов.
Изменение политики зеркалирования.

ПРИМЕЧАНИЕ

В версии 1.0 ggrebalance поддерживает изменение политики зеркалирования только для несбалансированных кластеров в рамках возврата в сбалансированное состояние.
Выполнение набора логических и физических изменений топологии в одной операции. Например, можно уменьшить количество сегментов, одновременно заменяя часть сегмент-хостов.

Перед запуском ggrebalance убедитесь, что кластер удовлетворяет следующим требованиям:

Кластер полностью работоспособен и не содержит сегментов в состоянии сбоя (down). Если некоторые сегменты кластера недоступны, запуск ggrebalance завершится с ошибкой. Перед запуском операций ребалансировки восстановите отказавшие сегменты с помощью gprecoverseg.
Кластер работает в обычном production-режиме. ggrebalance не может работать в режиме обслуживания (maintenance mode) или режиме только координатора (coordinator-only mode).
Новые сегмент-хосты должны быть настроены так же, как при расширении кластера с помощью gpexpand. Это включает:
- установку той же версии Greengage DB;
- подготовку каталогов данных;
- настройку SSH-подключения;
- обмен SSH-ключами;
- проверку доступности хостов и конфигурации окружения.

Кроме того, при использовании ggrebalance рекомендуется:

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

Хотя ggrebalance минимизирует простой, во время некоторых этапов выполнения доступность кластера временно снижается. Запуск ребалансировки во время окон обслуживания или в периоды низкой активности уменьшает влияние на рабочие нагрузки. Информацию о планировании сеансов ребалансировки на нужное время см. в разделе Запуск сеансов ребалансировки.
Создать свежий бэкап кластера с помощью gpbackup перед изменением топологии.

Хотя ggrebalance поддерживает возобновление прерванных операций и может автоматически откатывать незавершенные изменения, изменение топологии кластера несет риск ошибок или нарушения работы кластера. Инструкции по установке и использованию gpbackup приведены в документации gpbackup и gprestore.

См. также раздел Предварительные требования справочника по утилите ggrebalance.

План ребалансировки описывает:

какие экземпляры сегментов будут перемещены;
исходные и целевые хосты;
исходные и целевые каталоги данных;
предполагаемый объем передаваемых данных.

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

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

Чтобы генерация плана была детерминированной, запустите ggrebalance с параметром --seed, указав число, которое будет использоваться как начальное значение (seed) генератора случайных чисел. При разных запусках с одинаковым значением seed и одинаковыми параметрами топологии ggrebalance генерирует одинаковые планы ребалансировки. Это может быть полезно для тестирования, сравнения планов или повторного выполнения одинаковых изменений топологии. Текущее значение seed отображается в выводе ggrebalance в строке вида:

[INFO]:-Running randomized plan improvement with seed:112000605749072073190442187284282172932

Перед применением изменений топологии можно предварительно просмотреть сгенерированный план ребалансировки с помощью параметра --show-plan. Запустите ggrebalance с параметром --show-plan вместе с параметрами, определяющими целевую топологию:

$ ggrebalance --show-plan <other_options>

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

Пример плана ребалансировки

================================================================================
                                  SHRINK PLAN
================================================================================

Target Segment Count: 6

-------------------------------SEGMENTS TO REMOVE-------------------------------
Total segments to shrink: 2

  [1] Segment Pair:
      Primary:
        Content:  6
        DbId:     8
        Host:     sdw4
        Datadir:  /data1/primary/gpseg6
        Port:     10000
      Mirror:
        Content:  6
        DbId:     16
        Host:     sdw1
        Datadir:  /data1/mirror/gpseg6
        Port:     10500

  [2] Segment Pair:
      Primary:
        Content:  7
        DbId:     9
        Host:     sdw4
        Datadir:  /data1/primary/gpseg7
        Port:     10001
      Mirror:
        Content:  7
        DbId:     17
        Host:     sdw1
        Datadir:  /data1/mirror/gpseg7
        Port:     10501

---------------------------------BALANCE MOVES----------------------------------
Total moves planned: 6

  [1] Move Segment(content=0, dbid=10, role=m) [405.38 MB]
      From: sdw2:10500:/data1/mirror/gpseg0
      To:   sdw3:10502:/data1/mirror/gpseg0

  [2] Move Segment(content=1, dbid=11, role=m) [405.62 MB]
      From: sdw2:10501:/data1/mirror/gpseg1
      To:   sdw3:10503:/data1/mirror/gpseg1

  [3] Move Segment(content=2, dbid=4, role=p) [470.54 MB]
      From: sdw2:10000:/data1/primary/gpseg2
      To:   sdw4:10002:/data1/primary/gpseg2

  [4] Move Segment(content=2, dbid=12, role=m) [405.84 MB]
      From: sdw3:10500:/data1/mirror/gpseg2
      To:   sdw1:10502:/data1/mirror/gpseg2

  [5] Move Segment(content=3, dbid=5, role=p) [470.27 MB]
      From: sdw2:10001:/data1/primary/gpseg3
      To:   sdw4:10003:/data1/primary/gpseg3

  [6] Move Segment(content=3, dbid=13, role=m) [405.59 MB]
      From: sdw3:10501:/data1/mirror/gpseg3
      To:   sdw1:10503:/data1/mirror/gpseg3

================================================================================

Описания шагов плана содержат информацию о типе шага, а также о задействованных сегментах и хостах:

идентификатор содержимого сегмента;
идентификатор базы данных сегмента (dbid);
роль сегмента (p для основного сегмента, m для зеркального);
предполагаемый объем передаваемых данных (размеры сегментов до выполнения операции);
исходное расположение сегмента;
целевое расположение сегмента.

Проверяйте сгенерированный план перед выполнением операций ребалансировки, особенно при изменении количества сегментов или замене хостов.

Если сегменты распределены по хостам кластера неравномерно, ggrebalance может переместить их между хостами для восстановления сбалансированной топологии.

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

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

SELECT hostname, COUNT(content), role
FROM gp_segment_configuration
GROUP BY hostname, role ORDER BY hostname;

Разное количество основных или зеркальных сегментов на сегмент-хостах указывает на несбалансированный кластер. Пример:

 hostname | count | role
----------+-------+------
 mdw      |     1 | p
 sdw1     |     1 | m
 sdw2     |     1 | m
 sdw2     |     1 | p
 sdw3     |     2 | m
 sdw3     |     4 | p
 sdw4     |     4 | m
(8 rows)

Чтобы восстановить баланс кластера на том же наборе хостов, запустите ggrebalance, указав текущее количество основных сегментов в параметре -x/--target-segment-count:

$ ggrebalance -x 8

ПРИМЕЧАНИЕ

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

Во время ребалансировки ggrebalance обычно выполняет переключения — смену ролей между основными и зеркальными сегментами. Переключения временно прерывают доступ к соответствующей паре сегментов, пока зеркальный сегмент становится основным. Поэтому перед выполнением переключений ggrebalance запрашивает подтверждение. При появлении запросов на подтверждение переключения введите y:

Following switchovers require approval:
Rebalance step with move_order: 2, status: APPROVE_REQUIRED, type: switchover from Primary to Mirror, DBID 4

Approve switchovers? Yy|Nn (default=Y):

Чтобы автоматически подтверждать все переключения, используйте параметр -y/--approve-swap-roles. Подробнее см. Неинтерактивный режим.

После завершения операции ggrebalance выводит сводную информацию:

[INFO]:-Rebalance is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         13
[INFO]:-Rolled back moves:      0
[INFO]:-Cancelled moves:        0

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

ВАЖНО

ggrebalance 1.0 поддерживает только уменьшение количества сегментов (shrink). Чтобы увеличить количество сегментов, используйте утилиту gpexpand.

Операция уменьшения (shrink) уменьшает количество сегментов в кластере. Эта операция может быть полезна, если в кластере слишком много небольших сегментов по отношению к общему объему данных. В таких случаях накладные расходы на управление сегментами могут превышать выгоду от большей степени параллелизма.

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

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

Кластер с 12 сегментами на 3 хостах можно уменьшить до 9 или 6 сегментов.
Кластер с 8 сегментами на 4 хостах нельзя уменьшить до 6 сегментов без изменения физической топологии. Например, можно удалить один хост из кластера или добавить два новых.

Во время уменьшения ggrebalance удаляет сегменты с наибольшими значениями content_id и перераспределяет их данные между оставшимися сегментами. В результате размеры оставшихся сегментов увеличиваются, а перераспределение таблиц может создавать значительную временную нагрузку на I/O и сеть.

Чтобы уменьшить количество сегментов, сохранив тот же набор хостов, укажите целевое количество сегментов меньше текущего в параметре -x/--target-segment-count:

$ ggrebalance -x 6

Для некоторых шагов операции, включая переключения, может потребоваться подтверждение пользователя. Чтобы автоматически подтверждать переключения, используйте параметр -y/--approve-swap-roles. Чтобы автоматически выбирать параметры по умолчанию для всех запросов взаимодействия с пользователем во время операции, используйте неинтерактивный режим.

После завершения операции ggrebalance выводит сводную информацию:

[INFO]:-Shrink is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   SHRINK
[INFO]:-================================================================================
[INFO]:-Tables shrunk:		4
[INFO]:-Shrink total time:	0d 0h0m12s

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

Уменьшение без ребалансировки

ggrebalance может выполнять уменьшение без перераспределения итогового набора сегментов между хостами. Для этого используйте параметр --skip-rebalance:

$ ggrebalance -x 6 --skip-rebalance

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

Этот режим может быть полезен, когда:

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

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

Сначала удалите текущую схему ggrebalance:

$ ggrebalance -c

Затем запустите новую операцию ребалансировки, сохранив текущее количество сегментов:

$ ggrebalance -x 6

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

Удаление хостов для высвобождения аппаратных ресурсов.
Замена хостов во время обслуживания оборудования или миграции дата-центра.
Добавление хостов для распределения нагрузки между большим их количеством.

ПРИМЕЧАНИЕ

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

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

Целевой набор сегмент-хостов можно задать двумя способами:

Описать изменения относительно текущей топологии

Такой подход удобен для относительно небольших изменений топологии. В этом случае отдельно указываются:
- хосты, которые нужно удалить из кластера (параметр -R/--remove-hosts);
- хосты, которые нужно добавить в кластер (параметр -A/--add-hosts).
Например, пусть кластер содержит хосты sdw1, sdw2 и sdw3, и необходимо заменить sdw3 на sdw4. В этом случае удалите sdw3 и добавьте sdw4.
Задать полный целевой набор хостов

Такой подход более удобен для крупных изменений топологии, когда большинство существующих хостов заменяются или удаляются. В этом случае укажите полный список хостов, на которых должны работать сегменты после ребалансировки, с помощью параметра -H/--target-hosts.

Для приведенного выше примера укажите следующий список целевых хостов: sdw1,sdw2,sdw4. Все существующие сегмент-хосты, которых нет в списке (sdw3), будут удалены из кластера.

В обоих случаях списки хостов можно передавать либо в аргументах командной строки, либо через текстовые файлы. Для файловой конфигурации используйте аналогичные параметры с постфиксом *-file: --add-hosts-file, --remove-hosts-file и --target-hosts-file. Файл должен перечислять имена хостов по одному на строку.

По умолчанию на новых хостах ggrebalance создает следующие каталоги данных сегментов: /data1/primary/gpseg<N> и /data1/mirror/gpseg<N>. Чтобы использовать другие расположения каталогов данных, укажите их с помощью параметров -d/--target-datadirs или --target-datadirs-file. Значение состоит из двух путей к каталогам: каталога основных сегментов и каталога зеркальных сегментов. В значении параметра -d передавайте их одной строкой, разделяя запятой. При использовании --target-datadirs-file указывайте по одному каталогу в строке.

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

ВАЖНО

При изменении количества сегмент-хостов убедитесь, что сегменты могут быть равномерно распределены по итоговому набору хостов. Если сбалансированное распределение невозможно при текущем количестве сегментов, выполните комбинированное изменение топологии с изменением общего количества сегментов.

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

Чтобы удалить хосты, сохранив текущее количество сегментов:

укажите текущее количество сегментов как целевое (-x);
укажите хосты для удаления с помощью -R/--remove-hosts или --remove-hosts-file.

Пример:

$ ggrebalance -x 6 -R sdw4

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

$ ggrebalance -x 6 -R 'sdw4,sdw5,sdw6'

Вывод должен завершаться строками вида:

[INFO]:-Rebalance is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         9
[INFO]:-Rolled back moves:      0
[INFO]:-Cancelled moves:        0

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

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

Чтобы добавить хосты, сохранив текущее количество сегментов:

укажите текущее количество сегментов как целевое (-x);
укажите хосты для добавления с помощью -A/--add-hosts или --add-hosts-file.

Пример:

$ ggrebalance -x 6 -A sdw3

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

[INFO]:-Rebalance is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         9
[INFO]:-Rolled back moves:      0
[INFO]:-Cancelled moves:        0

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

Если кластер использует расположения каталогов данных сегментов, отличные от /data1/primary/gpseg<N> и /data1/mirror/gpseg<N> (по умолчанию), укажите их с помощью параметра -d/--target-datadirs. Пример:

$ ggrebalance -x 6 -A sdw3 \
   -d '/data2/primary,/data2/mirror'

Директории должны существовать на добавляемых хостах.

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

Чтобы заменить отдельные сегмент-хосты, используйте одновременно параметры удаления и добавления хостов -R/--remove-hosts и -A/--add-hosts:

$ ggrebalance -x 6 -R sdw3 -A sdw4

Если кластер использует расположения каталогов данных сегментов, отличные от стандартных, укажите их с помощью параметра -d/--target-datadirs.

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

[INFO]:-Rebalance is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         12
[INFO]:-Rolled back moves:      0
[INFO]:-Cancelled moves:        0

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

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

sdw1
sdw2
sdw3
sdw4

Укажите этот файл в параметре --target-hosts-file:

$ ggrebalance -x 6 --target-hosts-file target_hosts

ПРИМЕЧАНИЕ

В версии 1.0 ggrebalance поддерживает изменение политики зеркалирования только для несбалансированных кластеров в рамках возврата в сбалансированное состояние.

ggrebalance может изменять политику зеркалирования кластера во время ребалансировки с помощью параметра -m/--mirror-mode. Поддерживаются политики зеркалирования grouped и spread.

Утилита перераспределяет сегменты по хостам так, чтобы привести кластер к сбалансированной топологии в соответствии с выбранной политикой размещения зеркал. Например, чтобы изменить политику зеркалирования кластера, созданного с политикой grouped (по умолчанию), на spread, выполните следующую команду:

$ ggrebalance -x 8 -m spread

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

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

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

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

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

Чтобы выполнить комбинированное изменение топологии, задайте параметры целевой топологии с помощью соответствующих параметров:

целевое количество основных сегментов (-x/--target-segment-count);
сегмент-хосты для удаления и добавления (-R/--remove-hosts, -A/--add-hosts);
полный список целевых хостов (-H/--target-hosts);
целевые каталоги данных на новых хостах (-d/--target-datadirs);
политика зеркалирования (-m/--mirror-mode).

Как и в других сценариях ребалансировки, результирующая топология должна обеспечивать сбалансированное распределение сегментов.

Например, следующая команда уменьшает кластер до 6 сегментов, удаляет хосты sdw2 и sdw3 и добавляет хост sdw4:

$ ggrebalance -x 6 -R sdw3,sdw2 -A sdw4

При комбинированных операциях ggrebalance выполняет изменения топологии в несколько этапов.

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

После успешного завершения утилита выводит сводку с информацией обо всех выполненных этапах, например:

[INFO]:-Rebalance is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   SHRINK
[INFO]:-================================================================================
[INFO]:-Tables shrunk:		4
[INFO]:-Shrink total time:	0d 0h1m48s
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         12
[INFO]:-Rolled back moves:      0
[INFO]:-Cancelled moves:        0

После завершения операции выполните действия из раздела Дальнейшие шаги после ребалансировки.

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

ggrebalance предоставляет гибкие механизмы управления выполнением, которые помогают минимизировать влияние на доступность сервиса, контролировать ход ребалансировки и оптимально использовать доступные ресурсы. Эти механизмы позволяют администраторам:

Разделять длительные операции на несколько сеансов с ограниченным временем выполнения.
Контролировать использование ресурсов во время ребалансировки.
Уменьшать влияние на производственные нагрузки.
Отслеживать ход операции, чтобы заранее обнаруживать возможные проблемы и при необходимости выполнять откат операций.

ggrebalance поддерживает возобновляемые сеансы ребалансировки.

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

Чтобы запустить ограниченный по времени сеанс ребалансировки, используйте один из следующих параметров:

-T/--duration — запуск ребалансировки в течение заданного промежутка времени в формате HH:MM:SS.
-E/--end — запуск ребалансировки до указанного момента времени в формате YYYY-MM-DD HH:MM:SS.

Примеры:

Запустить сеанс ребалансировки длительностью пять минут:
```
$ ggrebalance -x 6 -T 00:05:00
```
Запуск ребалансировки до 9:00 31 мая 2026 года:
```
$ ggrebalance -x 6 -E "2026-05-31 09:00:00"
```

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

Чтобы позже продолжить прерванную операцию ребалансировки, используйте один из следующих способов:

Снова запустите ggrebalance без ограничений по времени, чтобы завершить операцию за один сеанс.
Запустите следующий ограниченный сеанс с помощью -T или -E.

Для повышения эффективности использования ресурсов и сокращения времени выполнения ggrebalance по возможности выполняет некоторые операции параллельно. Утилита предоставляет два независимых механизма управления параллелизмом:

-n/--parallel задает максимальное количество таблиц, одновременно обрабатываемых при операциях перераспределения таблиц, таких как уменьшение кластера.
-B/--batch-size задает максимальное количество операций перемещения сегментов, одновременно выполняемых во время этапа ребалансировки.

Пример:

$ ggrebalance -x 8 --parallel 8 --batch-size 4

Более высокая степень параллелизма может сократить общее время ребалансировки, но также увеличить загрузку CPU, нагрузку на I/O, что повлияет на выполнение активных запросов. Выбирайте параметры параллелизма в соответствии с доступными ресурсами кластера и операционными требованиями.

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

Чтобы избежать блокировки выполнения в ожидании пользовательского ввода, используйте неинтерактивный режим:

$ ggrebalance -x 6 --non-interactive-mode

В неинтерактивном режиме ggrebalance автоматически выбирает ответы по умолчанию для всех запросов.

Если требуется только автоматическое подтверждение смены ролей сегментов, используйте параметр -y/--approve-swap-roles. Пример:

$ ggrebalance -x 6 -y

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

Для мониторинга процесса ребалансировки доступны следующие способы:

служебная схема ggrebalance;
логи утилиты ggrebalance.

Схема ggrebalance автоматически создается в базе данных postgres при создании новой операции ребалансировки (вызов ggrebalance с параметром -x). Схема содержит таблицы и представления, описывающие прогресс ребалансировки и состояние операции:

ggrebalance.rebalance_progress содержит агрегированную информацию о ходе ребалансировки.

Пример запроса:

SELECT * FROM ggrebalance.rebalance_progress;

Пример результата:

           stat_name            | stat_value
--------------------------------+------------
 1.1. Tables shrunk             | 9
 1.2. Tables shrink in progress | 1
 1.3. Tables left to shrink     | 0
(3 rows)

При запуске ggrebalance с параметром -D/--detailed-progress становятся доступны дополнительные метрики, включая объем обработанных и оставшихся данных, а также оценки скорости обработки и оставшегося времени.

           stat_name            |       stat_value
--------------------------------+-------------------------
 1.1. Tables shrunk             | 9
 1.2. Tables shrink in progress | 1
 1.3. Tables left to shrink     | 0
 2.1. Bytes processed           | 154626408
 2.2. Bytes left to process     | 132349952
 2.3. Bytes in progress         | 132349952
 3.1. Estimated shrink rate     | 16.237520440730542 MB/s
 3.2. Estimated time            | 7.773277358493123 s
(8 rows)

ggrebalance.segment_move_steps хранит информацию о каждом шаге плана ребалансировки. Эту таблицу можно использовать для мониторинга перемещения сегментов.

Пример запроса:
```
SELECT move_order, status FROM ggrebalance.segment_move_steps ORDER BY move_order;
```
Пример результата:
```
 move_order |   status
------------+-------------
          0 | DONE
          1 | DONE
          2 | DONE
          3 | DONE
          4 | PLANNED
          5 | APPROVE_REQUIRED
          6 | PLANNED
          7 | APPROVE_REQUIRED
          8 | PLANNED
          9 | PLANNED
(10 rows)
```
Обратите внимание, что описания шагов хранятся в этой таблице в сериализованном виде и не пригодны для чтения. Сопоставляйте номера шагов с текстовым описанием плана, которое ggrebalance выводит перед выполнением операции.

ggrebalance.table_rebalance_status_detail хранит информацию о перераспределении отдельных таблиц.

Пример запроса:

SELECT * FROM ggrebalance.table_rebalance_status_detail;

Пример результата:

 db_name  | schema_name | rel_name | status | rebalance_type |       rebalance_started       |      rebalance_finished       | source_bytes
----------+-------------+----------+--------+----------------+-------------------------------+-------------------------------+--------------
 postgres | public      | table3   | none   | SHRINK         | 2026-05-26 09:28:31.580574+00 |                               |    132349952
 postgres | public      | table4   | done   | SHRINK         | 2026-05-26 09:28:31.584082+00 | 2026-05-26 09:28:36.956568+00 |     22447296
 postgres | public      | table2   | done   | SHRINK         | 2026-05-26 09:28:31.576651+00 | 2026-05-26 09:28:37.008942+00 |     22636880
 postgres | public      | table1   | none   | SHRINK         | 2026-05-26 09:28:31.557167+00 |                               |     64159744
(4 rows)

По умолчанию ggrebalance записывает логи выполнения в файлы с именами ggrebalance_YYYYMMDD.log. Эти файлы хранятся в подкаталоге gpAdminLogs домашнего каталога пользователя gpadmin на координатор-хосте. Изменить расположение лог-файлов ggrebalance можно с помощью параметра -l/--log-dir.

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

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

Дальнейшие шаги после ребалансировки

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

[INFO]:-Rebalance is complete

Кроме того, в таблице ggrebalance.rebalance_status появляется строка со значением state, равным STATE_EXECUTOR_DONE:

SELECT *
FROM ggrebalance.rebalance_status
WHERE state = 'STATE_EXECUTOR_DONE';

Пример результата:

        state        | state_category |            updated
---------------------+----------------+-------------------------------
 STATE_EXECUTOR_DONE | MAIN           | 2026-05-25 10:31:26.635473+00
(1 row)

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

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

Для удаления схемы выполните вызов ggrebalance с параметром -c/--clean:

$ ggrebalance -c

ПРИМЕЧАНИЕ

Пока в кластере существует схема ggrebalance, запуск новой операции ребалансировки невозможен.

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

Статистику можно собрать с помощью команды ANALYZE или утилиты analyzedb. Также можно использовать параметр -a/--analyze вызова ggrebalance для автоматического сбора статистики после завершения ребалансировки. Пример:

$ ggrebalance -x 6 -a

Имейте в виду, что это может значительно увеличить время выполнения операции при больших объемах данных.

Если во время ребалансировки возникает ошибка, ggrebalance по возможности пытается автоматически откатить уже выполненные изменения.

Кроме того, администраторы могут вручную откатывать завершенные или прерванные операции ребалансировки, пока существует схема ggrebalance.

Чтобы запустить откат, выполните:

$ ggrebalance -r

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

ВАЖНО

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

Пример вывода сводной информации об откате:

[INFO]:-Rebalance rollback is complete
[INFO]:------------------------------------SUMMARY--------------------------------------
[INFO]:-================================================================================
[INFO]:-                                   SHRINK
[INFO]:-================================================================================
[INFO]:-Tables shrunk:		4
[INFO]:-Shrink total time:	0d 0h0m11s
[INFO]:-================================================================================
[INFO]:-                                   REBALANCE
[INFO]:-================================================================================
[INFO]:-Segments moved:         0
[INFO]:-Rolled back moves:      10
[INFO]:-Cancelled moves:        0

Запуск и остановка

Резервное копирование и восстановление

Ребалансировка и изменение размера кластера

Обзор

Сбалансированное состояние

Утилита ggrebalance

Поддерживаемые изменения топологии

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

Просмотр плана ребалансировки

Возврат кластера в сбалансированное состояние

Изменение количества сегментов

Уменьшение

Изменение набора сегмент-хостов

Удаление сегмент-хостов

Добавление сегмент-хостов

Замена сегмент-хостов

Изменение политики зеркалирования

Комбинированные изменения топологии

Настройка процесса ребалансировки

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

Уровень параллелизма

Неинтерактивный режим

Мониторинг состояния ребалансировки

Схема ggrebalance

Лог-файлы утилиты ggrebalance

Дальнейшие шаги после ребалансировки

Удаление схемы ребалансировки

Сбор статистики

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