GitHub

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

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

Зеркалирование сегментов позволяет кластерам Greengage DB (на основе Greenplum) оставаться полностью доступными в случае отказа одного или нескольких сегментов. Когда сегмент выходит из строя, Greengage DB автоматически назначает его зеркало новым основным сегментом и продолжает обрабатывать пользовательские запросы. Транзакции, которые выполнялись в момент отказа, откатываются и автоматически перезапускаются после переключения на зеркало. Как следствие, сбои сегментов могут проходить незаметно для пользователей, если их зеркала продолжают работать.

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

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

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

Проверка вышедших из строя сегментов

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

Утилита gpstate

Утилита gpstate имеет параметр -e, который отображает информацию о сегментах с возможными проблемами зеркалирования:

  • Смена ролей между основными и зеркальными сегментами.

  • Несинхронизированные пары основных и зеркальных сегментов.

  • Сегменты в состоянии отказа (статус down).

$ gpstate -e

Пример вывода с проблемами зеркалирования:

[INFO]:-----------------------------------------------------
[INFO]:-Segment Mirroring Status Report
[INFO]:-----------------------------------------------------
[INFO]:-Segments with Primary and Mirror Roles Switched
[INFO]:-   Current Primary   Port    Mirror   Port
[INFO]:-   sdw1              11000   sdw2     10000
[INFO]:-   sdw1              11001   sdw2     10001
[INFO]:-----------------------------------------------------
[INFO]:-Unsynchronized Segment Pairs
[INFO]:-   Current Primary   Port    WAL sync remaining bytes   Mirror   Port
[INFO]:-   sdw1              10000   Unknown                    sdw2     11000
[INFO]:-   sdw1              10001   Unknown                    sdw2     11001
[INFO]:-   sdw1              11000   Unknown                    sdw2     10000
[INFO]:-   sdw1              11001   Unknown                    sdw2     10001
[INFO]:-----------------------------------------------------
[INFO]:-Downed Segments (may include segments where status could not be retrieved)
[INFO]:-   Segment   Port    Config status   Status
[INFO]:-   sdw2      11000   Down            Down in configuration
[INFO]:-   sdw2      11001   Down            Down in configuration
[INFO]:-   sdw2      10000   Down            Down in configuration
[INFO]:-   sdw2      10001   Down            Down in configuration

Если проблем не обнаружено, вывод заканчивается следующим сообщением:

[INFO]:-All segments are running normally

Таблицы gp_segment_configuration и gp_configuration_history

Таблица системного каталога gp_segment_configuration содержит метаданные обо всех сегментах кластера, включая их текущее состояние. Сегменты, которые вышли из строя, имеют значение d (down) в столбце status. Получить информацию об отказах сегментов можно с помощью следующего запроса:

SELECT * FROM gp_segment_configuration WHERE status='d';

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

 dbid | content | role | preferred_role | mode | status | port  | hostname | address |        datadir
------+---------+------+----------------+------+--------+-------+----------+---------+-----------------------
    6 |       0 | m    | m              | n    | d      | 11000 | sdw2     | sdw2    | /data1/mirror/gpseg0
    7 |       1 | m    | m              | n    | d      | 11001 | sdw2     | sdw2    | /data1/mirror/gpseg1
    4 |       2 | m    | p              | n    | d      | 10000 | sdw2     | sdw2    | /data1/primary/gpseg2
    5 |       3 | m    | p              | n    | d      | 10001 | sdw2     | sdw2    | /data1/primary/gpseg3
(4 rows)
ПРИМЕЧАНИЕ

Обратите внимание, что отказавшие сегменты, назначенные основными в конфигурации (значение preferred_role равно p), автоматически становятся зеркалами после отказа.

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

SELECT * FROM gp_configuration_history WHERE time BETWEEN '2025-04-29' AND '2025-04-30';

Пример строки таблицы gp_configuration_history:

             time              | dbid |                                     desc
-------------------------------+------+-------------------------------------------------------------------------------
 2025-04-29 04:38:18.248111+00 |    9 | FTS: update role, status, and mode for dbid 9 with contentid 3 to m, u, and s

Лог-файлы

Утилита gplogfilter выполняет поиск в логах Greengage DB по заданным критериям. Подробная информация о логах Greengage DB приведена в статье Логирование.

При использовании параметра -t (--trouble) утилита фильтрует записи типов ERROR, FATAL и PANIC. Они часто указывают на сбои сегментов или другие серьезные проблемы.

  • Чтобы проверить логи мастер-экземпляра:

    $ gplogfilter -t

    Для анализа конкретного лог-файла передайте путь к нему в качестве аргумента:

    $ gplogfilter -t $MASTER_DATA_DIRECTORY/pg_log/gpdb-2025-03-31_064402.csv

    Чтобы сохранить отфильтрованный вывод в файле для последующего анализа, используйте параметр -o (--out):

    $ gplogfilter -t -o master_issues

  • Чтобы проверить логи сегментов, используйте gpssh для выполнения одной и той же команды gplogfilter на всех сегмент-хостах. Например, для поиска в pg_log внутри каталогов данных сегментов:

    $ gpssh -f hostfile_segment_hosts -e " \
      source /usr/local/gpdb/greengage_path.sh && \
      gplogfilter /data1/*/*/pg_log/gpdb*.csv \
      --trouble"

    где <hostfile_segment_hosts> — это список сегмент-хостов кластера.

    Чтобы сохранить вывод логов сегментов для анализа на мастер-хосте, перенаправьте вывод gpssh в файл:

    $ gpssh -f hostfile_segment_hosts -e " \
      source /usr/local/gpdb/greengage_path.sh && \
      gplogfilter /data1/*/*/pg_log/gpdb*.csv \
      --trouble" > segment_issues

Восстановление отказавших сегментов

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

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

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

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

Типы восстановления после сбоя

СУБД Greengage поддерживает три типа восстановления сегментов после сбоя для различных сценариев:

  • Инкрементальное восстановление. Это метод по умолчанию для восстановления на месте. Greengage DB определяет различия между отказавшим сегментом и его исправным зеркалом, анализируя их WAL-файлы. Затем недостающие транзакции воспроизводятся с помощью утилиты pg_rewind, чтобы синхронизировать сегмент. Этот метод эффективный и быстрый, так как не требует полной передачи данных. Если при инкрементальном восстановлении сегмента происходит ошибка, требуется дифференциальное или полное восстановление.

  • Дифференциальное восстановление. Этот метод использует утилиту rsync для сравнения файловых систем отказавшего сегмента и его исправного зеркала. На целевой сегмент копируются только измененные файлы. Дифференциальное восстановление похоже на полное восстановление, но работает быстрее при восстановлении на месте, так как передает меньше данных. Используется, если инкрементное восстановление невозможно, но хочется избежать копирования полного объема данных.

  • Полное восстановление. Создает новый каталог данных сегмента с нуля, используя полную копию данных зеркала. Копирование выполняется с помощью утилиты pg_basebackup. При полном восстановлении на месте существующий каталог данных отказавшего сегмента удаляется. Это единственный возможный метод для переноса сегментов на другой хост, как на существующий в кластере, так и на новый.

Применимость типов восстановления по сценариям:

  • Восстановление на месте: инкрементальное, дифференциальное или полное.

  • Восстановление на другой хост в кластере: только полное.

  • Восстановление на новый хост: только полное.

Общий порядок действий

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

  1. Оцените, хотите ли вы восстановить сегмент на исходном хосте. Если нет или восстановление на месте невозможно, переходите сразу к последнему шагу.

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

  3. Если инкрементальное восстановление не удалось, попробуйте дифференциальное восстановление на месте.

  4. Если ни инкрементальное, ни дифференциальное восстановление не сработало, выполните полное восстановление. Это можно сделать либо на месте, либо на другом хосте (внутри кластера или новом).

Восстановление на месте

Чтобы восстановить все отказавшие сегменты на их исходных хостах (in-place), выполните инкрементальное восстановление:

  1. Запустите gprecoverseg:

    $ gprecoverseg

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

    [INFO]:----------------------------------------------------------
[INFO]:-Recovery 1 of 4
[INFO]:----------------------------------------------------------
[INFO]:-   Synchronization mode                 = Incremental
[INFO]:-   Failed instance host                 = sdw2
[INFO]:-   Failed instance address              = sdw2
[INFO]:-   Failed instance directory            = /data1/mirror/gpseg0
[INFO]:-   Failed instance port                 = 11000
[INFO]:-   Recovery Source instance host        = sdw1
[INFO]:-   Recovery Source instance address     = sdw1
[INFO]:-   Recovery Source instance directory   = /data1/primary/gpseg0
[INFO]:-   Recovery Source instance port        = 10000
[INFO]:-   Recovery Target                      = in-place

  2. Введите y и нажмите Enter для подтверждения восстановления:

    Continue with segment recovery procedure Yy|Nn (default=N):
    ПРИМЕЧАНИЕ

    Чтобы запустить восстановление без подтверждения, добавьте опцию -a:

    $ gprecoverseg -a

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

    [INFO]:-********************************
[INFO]:-Segments successfully recovered.
[INFO]:-********************************
[INFO]:-Recovered mirror segments need to sync WAL with primary segments.
[INFO]:-Use 'gpstate -e' to check progress of WAL sync remaining bytes

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

Частичное восстановление на месте

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

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

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

$ gprecoverseg -o recover_conf_file
Пример файла конфигурации восстановления

Следующий шаблон файла сгенерирован для кластера с четырьмя отказавшими сегментами на хосте sdw2:

# If any entry is commented, please know that it belongs to failed segment which is unreachable.
# If you need to recover them, please modify the segment entry and add failover details
# (failed_addresss|failed_port|failed_dataDirectory<space>failover_addresss|failover_port|failover_dataDirectory) to recover it to another host.

sdw2|11000|/data1/mirror/gpseg0
sdw2|11001|/data1/mirror/gpseg1
sdw2|10000|/data1/primary/gpseg2
sdw2|10001|/data1/primary/gpseg3

Сгенерированный файл построчно описывает все отказавшие сегменты в следующем формате:

failedAddress|failedPort|failedDataDirectory

или

failedHostname|failedAddress|failedPort|failedDataDirectory

Закомментируйте с помощью # или удалите строки сегментов, которые не нужно восстанавливать. Затем выполните восстановление оставшихся сегментов:

  1. Запустите gprecoverseg, передав имя файла в опции -i:

    $ gprecoverseg -i recover_conf_file

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

    [INFO]:----------------------------------------------------------
[INFO]:-Recovery 1 of 2
[INFO]:----------------------------------------------------------
[INFO]:-   Synchronization mode                 = Incremental
[INFO]:-   Failed instance host                 = sdw2
[INFO]:-   Failed instance address              = sdw2
[INFO]:-   Failed instance directory            = /data1/mirror/gpseg0
[INFO]:-   Failed instance port                 = 11000
[INFO]:-   Recovery Source instance host        = sdw1
[INFO]:-   Recovery Source instance address     = sdw1
[INFO]:-   Recovery Source instance directory   = /data1/primary/gpseg0
[INFO]:-   Recovery Source instance port        = 10000
[INFO]:-   Recovery Target                      = in-place

  2. Введите y и нажмите Enter для подтверждения восстановления:

    Continue with segment recovery procedure Yy|Nn (default=N):

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

    [INFO]:-********************************
[INFO]:-Segments successfully recovered.
[INFO]:-********************************
[INFO]:-Recovered mirror segments need to sync WAL with primary segments.
[INFO]:-Use 'gpstate -e' to check progress of WAL sync remaining bytes

После завершения частичного восстановления:

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

  • Восстановите остальные отказавшие сегменты, чтобы вернуть кластер к полностью рабочему состоянию.

Полное и дифференциальное восстановление на месте

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

Для выполнения полного восстановления используйте параметр -F команды gprecoverseg:

$ gprecoverseg -F
ПРЕДУПРЕЖДЕНИЕ

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

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

$ gprecoverseg -differential

Оба типа восстановления — полное и дифференциальное — можно выполнять для отдельных сегментов с помощью файла конфигурации восстановления:

$ gprecoverseg -F -i recover_conf_file

Восстановление на другом хосте

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

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

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

  • -o — имя выходного файла.

  • -p — целевой хост, на который будут восстановлены отказавшие сегменты.

$ gprecoverseg -o recover_out -p sdw3
ПРИМЕЧАНИЕ

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

$ gprecoverseg -o recover_out -p sdw3,sdw4
Пример файла конфигурации восстановления

Следующий шаблон сгенерирован вызовом gprecoverseg, показанным выше.

# If any entry is commented, please know that it belongs to failed segment which is unreachable.
# If you need to recover them, please modify the segment entry and add failover details
# (failed_addresss|failed_port|failed_dataDirectory<space>failover_addresss|failover_port|failover_dataDirectory) to recover it to another host.

sdw2|10500|/data1/mirror/gpseg0 sdw3|10002|/data1/mirror/gpseg0
sdw2|10501|/data1/mirror/gpseg1 sdw3|10003|/data1/mirror/gpseg1
sdw2|10000|/data1/primary/gpseg2 sdw3|10004|/data1/primary/gpseg2
sdw2|10001|/data1/primary/gpseg3 sdw3|10005|/data1/primary/gpseg3

Сгенерированный файл содержит список отказавших сегментов и их новых расположений на указанных хостах. Каждая строка имеет следующую структуру:

failedAddress|failedPort|failedDataDirectory newAddress|newPort|newDataDirectory

или

failedHostname|failedAddress|failedPort|failedDataDirectory newHostname|newAddress|newPort|newDataDirectory
ПРИМЕЧАНИЕ

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

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

Для частичного восстановления закомментируйте ненужные строки с помощью # или удалите их.

ВАЖНО

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

Выполните восстановление:

  1. Запустите gprecoverseg, передав имя файла в опции -i:

    $ gprecoverseg -i recover_conf_file

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

    [INFO]:----------------------------------------------------------
[INFO]:-Recovery 1 of 4
[INFO]:----------------------------------------------------------
[INFO]:-   Synchronization mode                 = Full
[INFO]:-   Failed instance host                 = sdw2
[INFO]:-   Failed instance address              = sdw2
[INFO]:-   Failed instance directory            = /data1/mirror/gpseg0
[INFO]:-   Failed instance port                 = 11000
[INFO]:-   Recovery Source instance host        = sdw1
[INFO]:-   Recovery Source instance address     = sdw1
[INFO]:-   Recovery Source instance directory   = /data1/primary/gpseg0
[INFO]:-   Recovery Source instance port        = 10000
[INFO]:-   Recovery Target instance host        = sdw3
[INFO]:-   Recovery Target instance address     = sdw3
[INFO]:-   Recovery Target instance directory   = /data1/mirror/gpseg0
[INFO]:-   Recovery Target instance port        = 10000

  2. Введите y и нажмите Enter для подтверждения восстановления:

    Continue with segment recovery procedure Yy|Nn (default=N):

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

    [INFO]:-********************************
[INFO]:-Segments successfully recovered.
[INFO]:-********************************
[INFO]:-Recovered mirror segments need to sync WAL with primary segments.
[INFO]:-Use 'gpstate -e' to check progress of WAL sync remaining bytes

После завершения восстановления:

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

  • Восстановите остальные отказавшие сегменты, чтобы вернуть кластер к полностью рабочему состоянию.

Восстановление на новом хосте

Хорошая практика — предусмотреть резервные хосты на случай отказа сегмент-хоста. Восстановление на новом хосте вне кластера выполняется так же, как и восстановление на другом существующем сегмент-хосте. Имя (или имена) нового хоста можно указать вручную в конфигурационном файле восстановления или сгенерировать такой файл с помощью параметра -p:

$ gprecoverseg -o recover_spare -p sdw-spare-1

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

Балансировка кластера

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

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

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

  • gpstate -m: наличие сегментов со статусом Acting as primary.

    [INFO]:--------------------------------------------------------------
[INFO]:--Current GPDB mirror list and status
[INFO]:--Type = Group
[INFO]:--------------------------------------------------------------
[INFO]:-   Mirror   Datadir                Port    Status              Data Status
[INFO]:-   sdw2     /data1/mirror/gpseg0   10000   Passive             Synchronized
[INFO]:-   sdw2     /data1/mirror/gpseg1   10001   Passive             Synchronized
[INFO]:-   sdw1     /data1/mirror/gpseg2   11000   Acting as Primary   Synchronized
[INFO]:-   sdw1     /data1/mirror/gpseg3   11001   Acting as Primary   Synchronized
[INFO]:--------------------------------------------------------------

  • gpstate -e: секция Segments with Primary and Mirror Roles Switched.

    [INFO]:-----------------------------------------------------
[INFO]:-Segments with Primary and Mirror Roles Switched
[INFO]:-   Current Primary    Port    Mirror    Port
[INFO]:-   sdw1               11000   sdw2      10000
[INFO]:-   sdw1               11001   sdw2      10001

Чтобы вернуть все сегменты к их исходным (предпочтительным) ролям:

  1. Выполните gprecoverseg с опцией -r:

    $ gprecoverseg -r

    Greengage DB выведет информацию о каждом сегменте, который требуется вернуть к исходной роли:

    [INFO]:----------------------------------------------------------
[INFO]:-Unbalanced segment 1 of 4
[INFO]:----------------------------------------------------------
[INFO]:-   Unbalanced instance host        = sdw1
[INFO]:-   Unbalanced instance address     = sdw1
[INFO]:-   Unbalanced instance directory   = /data1/mirror/gpseg2
[INFO]:-   Unbalanced instance port        = 11000
[INFO]:-   Balanced role                   = Mirror
[INFO]:-   Current role                    = Primary

  2. Введите y и нажмите Enter для подтверждения балансировки:

    Continue with segment rebalance procedure Yy|Nn (default=N):

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

    [INFO]:-The rebalance operation has completed successfully.

Чтобы убедиться, что все сегменты вернулись к исходным ролям, повторно выполните gpstate -e:

$ gpstate -e

В конце вывода должно быть сообщение:

[INFO]:-All segments are running normally
Предыдущая
Настройка зеркалирования
Следующая
Восстановление мастера после сбоев
Открыть страницу поиска