Мы уже писали про механизмы обеспечения высокой доступности в кластере Greenplum. Сегодня рассмотрим, какие инструменты и приемы помогут выявить сбои координатора и сегментов, а также как администратору кластера этой MPP-СУБД восстановить ее работоспособность.
Что такое зеркалирование сегментов Greenplum
Напомним, кластер Greenplum представляет собой несколько экземпляров популярной объектно-реляционной базы данных (БД) PostreSQL, которые работают вместе как единая СУБД без разделения ресурсов. Поскольку для внешних клиентов кластер MPP-СУБД представляется единым целым, необходима синхронизация узлов и/или центральная точка доступа. В Greenplum такой единой точкой клиентов к системе является экземпляр координатора, который хранит не пользовательские данные, а глобальный системный каталог и набор системных таблиц с метаданными об экземплярах БД. Если экземпляр координатора выходит из строя или становится недоступным, БД Greenplum фактически отключается, поскольку точка входа в систему потеряна. Поэтому необходим резервный координатор, готовый взять на себя управление в случае отказа основного. Такое свойство надежности системы обеспечивается за счет приема зеркалирования, когда создается зеркальное отображение каждой базы данных – копии, которые должны находиться на различных экземплярах сервера СУБД. Основной экземпляр сервера СУБД предоставляет базу данных клиентам, а зеркальный экземпляр выступает в качестве сервера горячей замены (горячего резерва). Зеркальное отображение базы данных означает, что в зеркальной базе данных повторяются все CRUD-операции, производимые в основной базе. Для этого поток записей активных транзакций с максимально возможной быстротой отправляется на зеркальный сервер. В отличие от репликации, которая работает на логическом уровне, зеркальное отображение базы данных работает на уровне физической записи журнала.
Координатор Greenplum также называют мастер-сервером, где развернут главный экземпляр PostgreSQL, к которому подключаются клиенты, отправляя SQL-запросы. Сами данные хранятся на серверах-сегментах. Сегменты Greenplum представляют собой экземпляры PostgreSQL, которые могут быть основными (primary) и зеркальными (mirror). Каждая ячейка сегментов Greenplum представляет собой независимую базу данных PostgreSQL, где хранится часть данных. Основной сегмент обрабатывает локальные данные, отдавая результаты мастеру. Каждому основному сегменту соответствует свое зеркало — экземпляр PostgreSQL, который автоматически включается в работу при отказе основного.
Каждый экземпляр сегмента Greenplum хранит и управляет частью данных БД при координации со стороны экземпляра координатора. При отсутствии зеркала сбой сегмента часто приводит к необходимости закрывать и восстанавливать базу данных, а транзакции после самой последней резервной копии, могут быть потеряны. Поэтому зеркалирование сегментов является важным элементом решения высокой доступности кластера, необходимого для нагруженных Big Data систем.
Зеркальное отображение координатора использует два процесса: отправителя на активном хосте-координаторе и получателя на зеркальном хосте для синхронизации зеркала с координатором. Когда изменения применяются к системным каталогам координатора, активный координатор передает свой журнал упреждающей записи (WAL, Write Ahead Log) на зеркало, чтобы каждая транзакция, примененная к координатору, применилась к зеркалу.
Благодаря наличию механизма определения недоступности сегмента, Greenplum автоматически активирует его зеркало. Когда активен основной экземпляр сегмента, данные реплицируются с основного на зеркальный двумя способами. Во-первых, используется журнал фиксации транзакций, который реплицируется с основного сервера на зеркальный до фактической фиксации транзакции. Это гарантирует наличие на активном зеркале изменений, сделанных последней успешной транзакцией на основном сервере. Во-вторых, зеркалирование сегментов использует репликацию физических файлов для обновления таблиц кучи. Сервер Greenplum хранит табличные данные на диске в виде блоков фиксированного размера, упакованных кортежами. Чтобы оптимизировать ресурсоемкие операции дискового ввода-вывода, блоки кэшируются в памяти до тех пор, пока кэш не заполнится, и некоторые блоки должны быть удалены, чтобы освободить место для недавно обновленных блоков. Когда блок удаляется из кэша, он записывается на диск и реплицируется на зеркало. Из-за механизма кэширования обновления таблиц на зеркале могут отставать от основного. Однако, поскольку журнал транзакций также реплицируется, зеркало остается согласованным с основным.
Координатор автоматически обнаруживает отказы сегментов и активирует зеркало. Процесс активации зеркала обновляет таблицы, применяя новые изменения в журнале фиксации транзакций. Когда действующий основной сервер не может получить доступ к своему зеркалу, репликация останавливается, а состояние основного сервера устанавливается на режим отслеживания изменений. Основной сервер сохраняет изменения, которые не были реплицированы на зеркало, в системной таблице для репликации, когда зеркало вернется в работу. Транзакции, выполнявшиеся на момент сбоя, перезапускаются с использованием нового основного.
В зависимости от развертывания зеркал на узлах кластера, распределенная база данных может быть несбалансированной, пока не будет восстановлен исходный основной сегмент. Например, если каждый узел сегмента имеет четыре основных и четыре зеркальных, а зеркало активировано на одном узле, он будет иметь пять активных основных сегментов. При этом запросы не завершатся, пока последний сегмент не завершит свою работу, поэтому производительность может снижаться до момента восстановления исходного основного сегмента.
Разобравшись с основными принципами обеспечения надежности кластера Grrenplum с помощью зеркалирования, далее рассмотрим, как администратору восстановить систему после сбоя.
Восстановление после сбоя
При восстановлении Greenplum после сбоя администратор кластера использует следующие утилиты:
- gpstate – для просмотра общего состояния системы;
- gprecoverseg— для восстановления отказавшего сегмента;
- gpactivatestandby— для активации резервного координатора.
В частности, для назначения резервного координатора в качестве основного, пользователь Greenplum с правами администратора должен запустить утилиту gpactivatestandby на резервном хосте, чтобы тот мог принимать клиентские подключения. Клиенты должны повторно подключиться к новому координатору. При этом возможна потеря всех изменений, которые не были зафиксированы при сбое основного координатора. Утилита gprecoverseg находит сегменты, в которых произошел сбой, проверяет их доступность и сравнивает состояние транзакций с текущим активным сегментом, чтобы определить изменения, сделанные в автономном режиме. Утилита gprecoverseg синхронизирует измененные файлы базы данных с активным сегментом и возвращает сегмент в оперативный режим. Поэтому для корректной работы зеркал зарезервировать на их хостах достаточно памяти и ресурсов ЦП, чтобы они могли работу в качестве основных сегментов во время сбоя.
Восстановление после системных сбоев требует вмешательства системного администратора, даже если Greenplum автоматически обнаружил сбой и активировал зеркало для отказавшего компонента. В любом случае отказавший компонент должен быть заменен или восстановлен для восстановления полного резервирования. Пока неисправный компонент не будет восстановлен, активный компонент не будет иметь резервной копии, что снижает надежность системы и делает ее несбалансированной. Поэтому важно оперативно выполнять операции по восстановлению с помощью специальных инструментов мониторинга.
Процесс обнаружения отказавшего сегмента выполняет сама система Greenplum. Подпроцесс сервера базы данных ftsprobe обрабатывает обнаружение ошибок, периодически сканируя все сегменты и процессы с интервалами, периодичность которых настраивается в параметре конфигурации gp_fts_probe_interval. Если подпроцесс ftsprobe не смог подключиться к сегменту, тот помечается как «неактивный» в системном каталоге Greenplum и остается отключенным, пока администратор не запустит утилиту восстановления gprecoverseg.
Проверить состояние кластера MPP-СУБД можно с помощью утилиты gpstate, изучив содержимое таблицы каталога gp_segment_configuration или лог-файлы. Утилита gpstate предоставляет статус каждого отдельного компонента Greenplum, включая основные и зеркальные сегменты, основной и резервный координаторы. Для отображения экземпляров сегментов с ошибочными состояниями следует запустить на хосте-координаторе утилиту gpstate с флагом –e:
$ gpstate –e
Если утилита показывает Segments with Primary and Mirror Roles Switched, то сегмент не находится в своей предпочтительной роли, которой он был назначен при инициализации системы. Это означает, что система находится в потенциально несбалансированном состоянии, поскольку некоторые хосты сегментов могут иметь больше активных сегментов, чем нужно для максимальной производительности системы. Если для какого-то зеркального сегмента утилита показывает статус конфигурации Down, это означает, что он не работает.
Обнаружить такие сегменты поможет таблица gp_segment_configuration, к которой нужно выполнить простой SQL-запрос на выборку данных:
$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"
Получить детальную информацию об экземплярах зеркального сегмента поможет команда $ gpstate с флагом –m.
Также обнаружить сбои сегментов и понять их причины, помогут лог-файлы. Каждый экземпляры координатора и сегмента имеет свой собственный лог-файл в log каталоге данных. Прежде всего следует проверить лог-файл координатора, который содержит больше всего информации. Найти дополнительные сведения в логах сегментов поможет утилита gplogfilter, которую надо запустить на узлах с помощью защищенной SSH-оболочки gpssh, работающей с множеством хостов. В частности, проверить лог-файлы координатора на наличие сообщений уровня WARNING, ERROR, FATAL или PANIC поможет команда gplogfilter с флагом –t. Аналогично, можно запустить эту команду в каждом экземпляре сегмента, например:
$ gpssh -f seg_hosts_file -e 'source /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t /data1/primary/*/log/gpdb*.log' > seglog.out
После обнаружения отключенных сегментов их надо восстановить на текущем хосте, другом узле кластера или выполнить полное восстановление на новый хост за пределами кластера. При восстановлении сегмента на прежнем хосте возможно сделать это инкрементально, что используется по умолчанию. Перед восстановлением важно убедиться в соблюдении следующих условий:
- зеркалирование включено для всех сегментов;
- понятно, какие сегменты вышли из строя;
- хост координатора может подключаться к хосту сегмента;
- все сетевые или аппаратные проблемы, вызвавшие сбой сегмента, устранены.
Для инкрементного восстановления всех сегментов, следует запустить утилиту gprecoverseg без параметров. Чтобы восстановить подмножество сегментов, надо вручную создать файл recover_config_file, в котором каждый восстанавливаемый сегмент имеет свою строку с форматом failedAddress|failedPort|failedDataDirectory. При восстановлении нескольких сегментов для каждого из них создается новая строка, с указанием адреса, номера порта и каталога данных, например:
failedAddress1|failedPort1|failedDataDirectory1failedAddress2|failedPort2|failedDataDirectory2failedAddress3|failedPort3|failedDataDirectory3
Также можно создать образец файла восстановления с помощью команды
$ gprecoverseg -o /home/gpadmin/recover_config_file
И передать этот файл в утилиту gprecoverseg с флагом -i:
$ gprecoverseg -i /home/gpadmin/recover_config_file
Для полного восстановления всех сегментов надо запустить утилиту gprecoverseg с флагом –F. Чтобы восстановить определенные сегменты, надо вручную создать файл recover_config_file, вписав туда для каждого восстанавливаемого сегмента строку в формате failedAddress1|failedPort1|failedDataDirectory1<SPACE>failedAddress2|failedPort2|failedDataDirectory2. В этом случае важно разделять строки символами <SPACE>. Вместо этого также можно можно создать образец файла восстановления и передать его в утилиту gprecoverseg с флагом –i.
Если надо обновить оборудование на хосте, на котором работают сегменты, выполняется восстановление на новый хост, т.е. полное восстановление. При этом новый хост должен иметь аналогичную версию Greenplum, что и отказавший, то же оборудование и конфигурацию ОС, включая имя хоста, версия ОС, параметры конфигурации, учетную запись пользователя gpadmin, созданные расположения каталогов данных, обмен ключами ssh, количество сетевых интерфейсов и соглашение об их именах сетевых интерфейсов. Также администратор кластера Greenplum должен убедиться в наличии достаточного места на диске для размещения сегментов и возможности подключаться без пароля ко всем другим существующим сегментам и координатору СУБД.
Восстановить все сегменты на новый хост поможет команда gprecoverseg -p <new_host_name>. Рекомендуется выполнять восстановление на один хост за раз, хотя при нескольких отказавших хостов сегмента можно указать новые узлы для восстановления в виде списка, разделенного запятыми. После полного или инкрементного восстановления сегмента надо убедиться в его статусе и списке предпочтительных ролей с помощью SQL-запроса select * from gp_segment_configuration. Следить за ходом синхронизации зеркала поможет утилита gpstate с флагом –e, а утилита gprecoverseg с флагом –r пригодится, чтобы вернуть сегментам их предпочтительные роли, если это необходимо.
Узнайте больше подробностей про администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://docs.vmware.com/en/VMware-Tanzu-Greenplum/7/greenplum-database/GUID-best_practices-ha.html
- https://docs.vmware.com/en/VMware-Tanzu-Greenplum/7/greenplum-database/GUID-admin_guide-highavail-topics-g-recovering-from-segment-failures.html
- https://docs.vmware.com/en/VMware-Tanzu-Greenplum/7/greenplum-database/GUID-admin_guide-highavail-topics-g-checking-for-failed-segments.html
