Рекомендуемые задачи по поддержке и мониторингу системы

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

Таблицы, представленные ниже, описывают действия администратора по поддержанию

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

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

Мониторинг состояния Базы данных

Действие	Процедура	Корректирующие действия
Перечислить сегменты, которые в данный момент не работают. Если будут возвращены какие-либо строки, то должно быть выдано предупреждение или уведомление. Рекомендуемая периодичность выполнения: каждые 5-10 минут Важность: ВЫСОКАЯ	Запустите следующий запрос в БД postgres : SELECT * FROM gp_segment_configuration WHERE status = 'd';	Если запрос возвращает какие-либо строки, выполните следующие действия: Убедитесь, что хосты с неработающими сегментами реагируют на запросы. Если с хостами все в порядке, проверьте файлы журналов для первичных и зеркальных сегментов, чтобы найти основную причину выхода сегментов из строя. Если ошибок не обнаружено, запустите утилиту gprecoverseg для восстановления работоспособности сегментов.
Проверка на наличие сегментов, которые работают и не синхронизированы. Если строки возвращаются, то должно быть предупреждение или уведомление. Рекомендуемая периодичность выполнения: выполнение каждые 5-10 минут	Выполните следующий запрос в базе данных postgres: SELECT * FROM gp_segment_configuration WHERE mode = 'n' and status = 'u' and content <> -1;	Если запрос возвращает строки, то, возможно, сегмент находится в процессе перехода из режима Not In Sync в режим Synchronized. Для отслеживания процесса используйте gpstate -e.
Проверьте наличие сегментов, которые не работают, но отмечены как up и Synchronized. Если такие сегменты найдены, кластер может быть не сбалансирован. Если будут возвращены какие-либо строки, то это должно привести к появлению предупреждения или оповещения. Рекомендуемая периодичность выполнения: каждые 5-10 минут Важность: ВЫСОКАЯ	Выполните следующий запрос в базе данных postgres: SELECT * FROM gp_segment_configuration WHERE preferred_role <> role and status = 'u' and mode = 's';	Если сегменты работают неверно, обработка может быть искажена. Выполните команду gprecoverseg -r, чтобы вернуть сегменты в их первоначальные роли.
Запустите распределенный запрос для того, чтобы проверить, что он выполняется на всех сегментах. Для каждого первичного сегмента должна быть возвращена одна строка. Рекомендуемая периодичность выполнения: каждые 5-10 минут Важность: КРИТИЧЕСКИ ВАЖНО	Выполните следующий запрос в базе данных postgres: SELECT gp_segment_id, count(*) FROM gp_dist_random('pg_class') GROUP BY 1;	Если этот запрос не выполняется, значит, возникла проблема с диспетчеризацией некоторых сегментов в кластере. Это редкое явление. Проверьте узлы, на которые не удается выполнить диспетчеризацию, чтобы убедиться в отсутствии аппаратных или сетевых проблем.
Проверьте состояние зеркалирования мастера на базе данных Greenplum. Если значение не равно "STREAMING", Вы увидите предупреждение. Рекомендуемая периодичность выполнения: каждые 5-10 минут Важность: ВЫСОКАЯ	Выполните следующую команду: psql <dbname> -c 'SELECT pid, state FROM pg_stat_replication;'	Проверьте файл журнала главного и резервного сервера на наличие ошибок. Если ошибок нет, и сервер не работает, запустите утилиту gpinitstandby, чтобы перевести резервную машину в режим онлайн.
Выполните базовую проверку работоспособности мастера. Рекомендуемая периодичность выполнения: каждые 5-10 минут Важность: КРИТИЧСКИ ВАЖНО	Выполните следующий запрос в базе данных postgres: SELECT count(*) FROM gp_segment_configuration;	Если этот запрос не выполняется, возможно, активный мастер не работает. Попробуйте запустить базу данных на исходном мастере. Если и это не удается, попробуйте активировать резервный мастер в качестве основного мастера.

Действие

Процедура

Корректирующие действия

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

Рекомендуемая периодичность выполнения: каждые 5-10 минут

Важность: ВЫСОКАЯ

Запустите следующий запрос в БД postgres :

SELECT * FROM gp_segment_configuration

WHERE status = 'd';

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

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

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

Рекомендуемая периодичность выполнения: выполнение каждые 5-10 минут

Выполните следующий запрос в базе данных postgres:

SELECT * FROM gp_segment_configuration

WHERE mode = 'n' and status = 'u' and content <> -1;

Если запрос возвращает строки, то, возможно, сегмент находится в процессе перехода из режима Not In Sync в режим Synchronized. Для отслеживания процесса используйте gpstate -e.

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

Рекомендуемая периодичность выполнения: каждые 5-10 минут

Важность: ВЫСОКАЯ

Выполните следующий запрос в базе данных postgres:

SELECT * FROM gp_segment_configuration

WHERE preferred_role <> role and status = 'u' and mode = 's';

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

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

Рекомендуемая периодичность выполнения: каждые 5-10 минут

Важность: КРИТИЧЕСКИ ВАЖНО

Выполните следующий запрос в базе данных postgres:

SELECT gp_segment_id, count(*)

FROM gp_dist_random('pg_class')

GROUP BY 1;

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

Проверьте состояние зеркалирования мастера на базе данных Greenplum. Если значение не равно "STREAMING", Вы увидите предупреждение.

Рекомендуемая периодичность выполнения: каждые 5-10 минут

Важность: ВЫСОКАЯ

Выполните следующую команду:

psql <dbname> -c 'SELECT pid, state FROM pg_stat_replication;'

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

Выполните базовую проверку работоспособности мастера.

Рекомендуемая периодичность выполнения: каждые 5-10 минут

Важность: КРИТИЧСКИ ВАЖНО

Выполните следующий запрос в базе данных postgres:

SELECT count(*) FROM gp_segment_configuration;

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

Мониторинг работоспособности системы

Действие	Процедура	Корректирующие действия
Проверьте использование дискового пространства, используемого для хранения данных Greenplum Database и ОС. Рекомендуемая периодичность выполнения: каждые 5-30 минут Важность: КРИТИЧЕСКИ ВАЖНО	Настройте проверку дискового пространства. Установите порог, при достижении которого диск заполняется на определенный процент. Рекомендуемое пороговое значение - 75%. Не рекомендуется запускать систему с заполненностью, близкой к 100%.	Используйте VACUUM/VACUUM FULL для очищения таблиц от ненужных строк.
Проверьте систему на наличие ошибок. Рекомендуемая периодичность выполнения: каждый час Важность: ВЫСОКАЯ	Настройка проверок сетевого интерфейса.	Работа с сетевыми командами и командами ОС для устранения ошибок.
Проверьте наличие ошибок RAID-массива или снижение его производительности. Рекомендуемая периодичность выполнения: каждые 5 минут Важность: КРИТИЧЕСКИ ВАЖНО	Запустить проверку RAID.	Как можно скорее замените диски, вышедшие из строя. Совместно с командой системного администрирования как можно скорее устраните другие ошибки RAID-массива или контроллера.
Проверьте пропускную способность канала ввода-вывода и возможные перекосы. Рекомендуемая периодичность выполнения: при создании кластера/ при подозрении на аппаратные проблемы.	Запустите утилиту Greenplum gpcheckperf.	Кластер может работать не корректно, если скорость передачи данных не такая: 2 ГБ в секунду на чтение с диска 1 ГБ в секунду при записи на диск чтение и запись по сети со скоростью 10 Гбит/с. Если скорость передачи данных ниже, проконсультируйтесь с архитектором БД относительно ожидаемой производительности системы.

Мониторинг каталога

Действие	Процедура	Корректирующие действия
Запустите проверку согласованности каталогов в каждой базе данных, чтобы убедиться, что каталог на каждом узле кластера согласован и находится в хорошем состоянии. Эту команду можно выполнять, пока база данных находится в рабочем состоянии. Рекомендуемая периодичность выполненич: еженедельно Важность: ВЫСОКАЯ	Запустите утилиту gpcheckcat в каждой базе данных: gpcheckcat -O Примечание: При использовании опции -O утилита gpcheckcat выполняет только 10 из своих обычных 15 тестов.	Запустите сценарии восстановления для всех выявленных проблем.
Проверка на наличие записей pg_class, не имеющих соответствующих записей pg_attribute. Рекомендуемая периодичность выполнения: ежемесячно Важность: ВЫСОКАЯ	Во время простоя, когда в системе нет пользователей, запустите утилиту gpcheckcat в каждой базе данных: gpcheckcat -R pgclass	Запуск скрипты ремонта для всех выявленных проблем.
Проверка на утечку временной схемы и отсутствие определения схемы. Рекомендуемая периодичность выполнения: ежемесячно Важность: ВЫСОКАЯ	Во время простоя, когда в системе нет пользователей, запустите утилиту gpcheckcat в каждой базе данных: gpcheckcat -R namespace	Запуск скрипты ремонта для всех выявленных проблем.
Проверка ограничений на случайно распределенных таблицах. Рекомендуемая периодичность выполнения: ежемесячно Важность: ВЫСОКАЯ	Во время простоя, когда в системе нет пользователей, запустите утилиту gpcheckcat в каждой базе данных: gpcheckcat -R distribution_policy	Запуск скрипты ремонта для всех выявленных проблем.
Проверка на наличие зависимостей от несуществующих объектов. Рекомендуемая периодичность выполнения: ежемесячно Важность: ВЫСОКАЯ	Во время простоя, когда в системе нет пользователей, запустите утилиту gpcheckcat в каждой базе данных: gpcheckcat -R dependency	Запуск скрипты ремонта для всех выявленных проблем.

Поддержка данных

Действие	Процедура	Корректирующие действия
Проверка на отсутствие статистики в таблицах.	Проверьте представление gp_stats_missing в каждой базе данных: SELECT * FROM gp_toolkit.gp_stats_missing;	Выполните ANALYZE для таблиц, по которым отсутствует статистика.
Проверка таблиц на наличие "раздутого" (мертвого) пространства в файлах данных, которое не может быть восстановлено обычной командой VACUUM. Рекомендуемая периодичность выполнения: еженедельно или ежемесячно	Проверьте представление gp_bloat_diag в каждой базе данных: SELECT * FROM gp_toolkit.gp_bloat_diag;	VACUUM FULL приобретает блокировку ACCESS EXCLUSIVE на таблицы. Запускайте VACUUM FULL в то время, когда пользователям и приложениям не требуется доступ к таблицам, например, в период низкой активности или во время окна обслуживания.

Действие

Процедура

Корректирующие действия

Проверка на отсутствие статистики в таблицах.

Проверьте представление gp_stats_missing в каждой базе данных:

SELECT * FROM gp_toolkit.gp_stats_missing;

Выполните ANALYZE для таблиц, по которым отсутствует статистика.

Проверка таблиц на наличие "раздутого" (мертвого) пространства в файлах данных, которое не может быть восстановлено обычной командой VACUUM.

Рекомендуемая периодичность выполнения: еженедельно или ежемесячно

Проверьте представление gp_bloat_diag в каждой базе данных:

SELECT * FROM gp_toolkit.gp_bloat_diag;

VACUUM FULL приобретает блокировку ACCESS EXCLUSIVE на таблицы. Запускайте VACUUM FULL в то время, когда пользователям и приложениям не требуется доступ к таблицам, например, в период низкой активности или во время окна обслуживания.

Поддержка базы данных

Действие	Процедура	Корректирующие действия
Освободить место, занимаемое удаленными строками в таблицах кучи, чтобы можно было повторно использовать занимаемое ими пространство. Рекомендуемая периодичность выполнения: ежедневно Важность: КРИТИЧЕСКИ ВАЖНО	Очистите таблицы при помощи: VACUUM <table>;	Регулярно очищайте таблицы для предотвращения их «вздутия».
Обновить статистику таблицы. Рекомендуемая периодичность выполнения: после загрузки данных и перед выполнением запросов Важность: КРИТИЧЕСКИ ВАЖНО	Анализируйте пользовательские таблицы. Используйте утилиту analyzedb: analyzedb -d <database> -a	Регулярно анализируйте обновляемые таблицы, только тогда оптимизатор сможет создавать эффективные планы выполнения запросов.
Осуществляйте резервное копирование данных БД. Рекомендуемая периодичность выполнения: ежедневно или в соответствии с требованиями плана резервного копирования Важность: КРИТИЧЕСКИ ВАЖНО	Запустите утилиту gpbackup для параллельного создания резервной копии главной и сегментной баз данных.	Лучше всего иметь наготове текущую резервную копию на случай необходимости восстановления базы данных.
Очищайте, реиндексируйте и анализируйте системные каталоги для поддержания эффективной работы каталога. Рекомендуемая периодичность выполнения: еженедельно или чаще, если объекты базы данных создаются и удаляются достаточно часто	Запустите VACUUM в системных таблицах каждой БД. Запустите REINDEX SYSTEM в каждой БД или испольуйте комманду reindexdb: reindexdb -s <database> Запустите ANALYZE для каждой системной таблицы: analyzedb -s pg_catalog -d <database>	Оптимизатор получает информацию из системных таблиц для создания планов запросов. Если системные таблицы и индексы со временем раздуваются, то сканирование системных таблиц увеличивает время выполнения запросов. Важно выполнять ANALYZE после переиндексации, поскольку при REINDEX индексы остаются без статистики.

Обновление

Действие	Процедура	Коррекционные действия
Обеспечьте применение всех исправлений и улучшений по отношению к ядру. Рекомендуемая периодичность выполнения: не реже одного раза в 6 месяцев Важность: ВЫСОКАЯ	Следуйте инструкциям по обновлению от вендора Linux.	Поддерживайте ядро в актуальном рабочем состоянии для того, чтобы включить в него исправления ошибок и безопасности, а также избежать возможных трудностей при обновлении в будущем.
Установите минорные релизы Greenplum, например 5.0.x. Рекомендуемая периодичность выполнения: раз в квартал Важность: ВЫСОКАЯ	Следуйте инструкциям по обновлению Greenplum. Всегда обновляйтесь до самой последней версии.	Поддерживайте ПО Greenplum в актуальном рабочем состоянии, чтобы включить в возможность исправления ошибок, повышения производительности и расширения функциональных возможностей.

Действие

Процедура

Коррекционные действия

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

Рекомендуемая периодичность выполнения: не реже одного раза в 6 месяцев

Важность: ВЫСОКАЯ

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

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

Установите минорные релизы Greenplum, например 5.0.x.

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

Важность: ВЫСОКАЯ

Следуйте инструкциям по обновлению Greenplum. Всегда обновляйтесь до самой последней версии.

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

← Предыдущая статья

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

Следующая статья →

GreenPlum. Обзорная информация