В статье рассматривается исполнительная часть утилиты ggrebalance: механизм физического перемещения primary- и mirror-сегментов между хостами кластера Greengage DB (open-source форк Greenplum), устройство конечного автомата ребаланса, отслеживание статусов операций, обработка сбоев и реентерабельность, откат перемещений, а также практические рекомендации по эксплуатации и итоговое сравнение с альтернативными инструментами.
В предыдущей части мы детально рассмотрели механизм планирования: как планировщик ggrebalance строит список перемещений сегментов для их равномерного распределения по хостам, и какие сценарии он охватывает — шринк, добавление хостов, декомиссия. Теперь речь пойдет о том, как именно этот план воплощается в жизнь: как сегменты физически перемещаются между машинами работающего кластера.
3.1 Проблемы перемещения сегментов
Перенос сегмента с данными — фундаментально сложная задача. Сегмент Greengage — полноценный экземпляр PostgreSQL, который обслуживает свою долю каждого распределенного запроса, участвует в двухфазном коммите, непрерывно стримит WAL, взаимодействует с механизмом FTS (Fault Tolerance Service) и т.д. Его адрес, порт и путь к данным зафиксированы в gp_segment_configuration — таблице, к которой диспетчер обращается при маршрутизации каждого запроса. Любое рассогласование между каталогом и реальным состоянием сегмента немедленно нарушает работу кластера. Также и перемещение сегмента может нарушить его работу, поэтому без должной предварительной…
