Главная
→
Кейсы
→
Восстановление Greenplum

Восстановление Greenplum после массового отказа сегментов и блокировки системного каталога

Проблематика

В администрировании распределенных баз данных случаются ситуации, когда стандартные инструкции перестают работать. Недавно команда DB Serv столкнулась со сложным кейсом: в кластере Greenplum (Master + 6 сегмент-хостов) одновременно «выпали» 14 сегментов.

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

Анализ проблемы и первичная диагностика

Мониторинг Arenadata Monitor и Grafana зафиксировал критическое состояние:

Database Segments: 4% (14 единиц) в статусе Down

Mirrors as Primaries: 14 зеркал были вынуждены взять на себя нагрузку упавших основных сегментов

Нагрузка: Всплески утилизации на выживших сегментах из-за перераспределения ролей

Проверка через gpstate -e выявила, что сбои локализованы на конкретных хостах: Segment3, Segment4 и Segment6. При этом сами серверы были доступны по SSH и имели низкий Load Average.

В логах сегментов (pg_log) мы обнаружили записи: received fast shutdown request и aborting any active transactions. Это подтвердило, что сегменты не «упали» физически, а были остановлены мастером (FTS), который посчитал их недоступными из-за сетевого лага или внутренних блокировок.

Технический тупик: Catalog Deadlock

Попытка запустить восстановление через gprecoverseg -a привела к зависанию на этапе Obtaining Segment details from master.... Логи утилиты показали остановку на строке: recoverseg:Master:gpadmin-[DEBUG]:-Connecting to dbname='template1'.

Это классический Catalog Deadlock. Системный каталог Мастера был заблокирован, что не позволяло утилитам даже прочитать конфигурацию сегментов.

Решение и пошаговый план реанимации

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

Шаг А: Разблокировка Мастера

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

gpstop -M fast (завис из-за блокировок).
gpstop -M immediate — экстренная остановка всех процессов.
gpstart -a — холодный старт с автоматическим Crash Recovery.

Шаг Б: Восстановление сегментов (Recovery)

После очистки shared memory Мастера утилита gprecoverseg -a отработала штатно. Она перевела сегменты из состояния Down в Up, синхронизировав дельту данных.

Шаг В: Ребалансировка ролей (Rebalance)

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

Bash

gprecoverseg -ar

Это вернуло Primaries на их родные узлы (Segment3, 4, 6), полностью восстановив симметрию кластера.

Экспертиза DB Serv: Как мы предотвращаем подобные инциденты

Чтобы избежать «эффекта домино» и зависаний в будущем, мы внедрили для клиента следующие Best Practices:

Тюнинг FTS-тайм-аутов

Увеличили gp_fts_probe_timeout до 60 секунд, чтобы исключить ложные срабатывания при кратковременных сетевых пиках.

Гигиена системного каталога

Настроили регулярный VACUUM для таблиц pg_catalog, что предотвращает замедление работы административных утилит.

Мониторинг блокировок

Настроили алертинг в Grafana на наличие транзакций, удерживающих блокировки более 5 минут.

Мониторинг длинных транзакций

Настроили алертинг на длинные транзакции (12+ часов) с последующим их отрубанием ( запрос от Заказчика)

Надёжность в каждом процессе

Вашему кластеру Greenplum нужна профессиональная поддержка? Или Monitoring? Эксперты DB Serv обеспечивают стабильность даже в самых сложных сценариях. Узнайте больше о наших услугах администрирования Greenplum

Оставить заявку Читать другие кейсы