Трудно представить, чем может обернуться для компании сбой в работе СУБД. Но, к сожалению, такое случается. И если база данных стала недоступна, то чем быстрее она будет восстановлена, тем меньшими потерями можно будет обойтись. Именно поэтому очень важно вести мониторинг баз данных и серверов СУБД, своевременно узнавать о сбоях и их характере.
Настроить мониторинг базы данных SQL можно с помощью российской программы «10-Страйк: Мониторинг Сети». Добавьте проверку "MySQL", "MSSQL" или "ODBC" и настройте параметры подключения, указав адрес SQL-сервера базы данных, порт, логин и пароль. Выберите метрику для мониторинга или задайте SQL-запрос, который получать значения из таблиц базы данных. Программа с заданной частотой подключается к базе данных и выполняет тестовый SQL-запрос, удостоверяясь тем самым в нормальной работе СУБД. В случае возвращения базой признака успешного подключения, проверка считается пройденной.
Кроме этого, программа может выполнить произвольный SQL-запрос, получить и оценить значение заданного параметра. Таким образом, можно организовать мониторинг значений, хранящихся в СУБД.
Поддерживаются следующие СУБД:
• MSSQL
• mySQL
• любая другая, поддерживающая подключение через ODBC-интерфейс (MSAccess®, Oracle®, Sybase, FireBird, и многие другие).
Мониторинг состояния базы данных обеспечивает поддержку её высокой производительности и доступности. Мониторинг баз данных включает в себя контроль множества параметров и метрик, которые предоставляет СУБД, а также выявление ошибок в её работе.
На примере MySQL опишем несколько основных метрик, по которым можно судить о состоянии базы данных.
1. Доступность базы данных и аптайм
Доступность базы данных можно проверить подключением к ней с удалённых хостов. Ошибка подключения может говорить об остановке сервиса базы данных или блокировке порта БД сторонними программами.
Узнать о быстрых перезапусках базы данных помогает параметр uptime. Такие перезапуски могут не попасть в поле зрения проверки доступности, поэтому имеет смысл проверять, как долго база данных работает без отказов и остановок. К примеру, можно задать порог срабатывания сигнализации при
uptime < 1800
где 1800 — время работы базы данных в секундах с последнего запуска.
2. Ошибки подключения к базе данных
Одной из проблем в работе базы данных являются ошибки подключения новых клиентов. Метрика Количество ошибок подключения позволяет определить моменты, когда база данных слишком часто генерирует эти ошибки. В неё входят следующие переменные состояния сервера MySQL (счётчики):
- Connection_errors_accept
Количество ошибок, возникших во время вызовов accept() на прослушивающем порту. - Connection_errors_internal
Количество соединений, отклоненных из-за внутренних ошибок сервера, таких как невозможность запуска нового потока или нехватка памяти. - Connection_errors_max_connections
Количество соединений, отклоненных из-за достижения ограничения сервера max_connections. - Connection_errors_peer_address
Количество ошибок, возникших при поиске подключающихся IP-адресов клиентов. - Connection_errors_select
Количество ошибок, возникших во время вызовов select() или poll() на прослушивающем порту. (Сбой этой операции не обязательно означает, что подключение клиента было отклонено). - Connection_errors_tcpwrap
Количество соединений, отклоненных библиотекой libwrap.
Если в настройках сервера MySQL неверно задан параметр max_connections, то при большом количестве одновременных подключений база данных может давать отказ, увеличивая счётчик Connection_errors_max_connections. Предупредить такую ситуацию можно, отслеживая отношение количества текущих подключений к максимально возможному. С этой целью подойдёт такой запрос:
SELECT ROUND(100 - (100 * Variable_value / [max_connections]), 0) as tc FROM sys.metrics where Variable_name = 'threads_connected'
в котором вместо [max_connections] нужно подставить актуальное значение параметра max_connections (по умолчанию он установлен в 100). Получить его можно запросом в консоли MySQL:
show variables like "max_connections";
Данная команда возвратит примерно такой результат:
Переменная запроса tc покажет процент доступных подключений, и пороговым значением можно установить 30%.
3. Медленные запросы к СУБД
MySQL ведёт журнал медленных запросов. Количество записей в этом журнале можно узнать с помощью метрики slow_queries. Запросить её значение можно простым SQL-запросом:
SELECT Variable_value FROM sys.metrics where Variable_name = 'slow_queries'
Программа может реагировать на изменение этого параметра, сообщая о появлении новых записей в журнале медленных запросов, что может означать проблемы с производительностью.
4. Запросы JOIN
Используя счётчики выполнения запросов join можно получать уведомления об операциях, которые затрачивают слишком много ресурсов.
- Select_full_join
Количество объединений, выполняющих сканирование таблиц, поскольку они не используют индексы. Если это значение не равно 0, вам следует тщательно проверить индексы ваших таблиц. - Select_full_range_join
Количество объединений, в которых использовался поиск по диапазону в справочной таблице. - Select_range_check
Количество объединений без ключей, которые проверяют использование ключа после каждой строки. Если их не 0, то вам следует тщательно проверить индексы ваших таблиц. - Select_scan
Количество объединений, которые выполнили полное сканирование первой таблицы. - Select_range
Количество объединений, в которых использовались диапазоны в первой таблице. Обычно это не критическая проблема, даже если значение довольно велико.
5. Частота попаданий в кэш
MySQL использует кэш в памяти для оптимизации операций чтения и записи на диск. Низкий процент попаданий в кэш (Cache Hit Rate) влияет на производительность базы данных. Этот запрос помогает вычислить значение частоты попаданий в кэш открытых таблиц:
SELECT ROUND((open_cache_hits / (open_cache_hits + open_cache_misses)), 2) * 100 OpenTableFactor FROM (SELECT variable_value open_cache_misses FROM sys.metrics WHERE variable_name = 'table_open_cache_misses') miss, (SELECT variable_value open_cache_hits FROM sys.metrics WHERE variable_name = 'table_open_cache_hits') hits;
Задайте порог OpenTableFactor в 90%, и в случае, если значение будет меньше, программа оповестит вас.
6. Время выполнения SQL-запроса
Еще одним показателем падения производительности базы данных является время выполнения запроса. Можно написать тестовый SQL и замерить время его выполнения в нормальных условиях. Полученное значение можно использовать как пороговое для этой проверки. Значительное превышение времени выполнения запроса в течение длительного периода может говорить о том, что база данных сильно загружена, и пользователям приходится долго ждать от неё ответа.
В MySQL большое количество метрик, позволяющих оценить работоспособность базы данных. Большая часть из них находится в системных таблицах INFORMATION_SCHEMA (sys). Таблицы и представления этой схемы доступны для выборки данных. Программа поддерживает выполнение произвольных запросов, позволяя создавать широкий спектр проверок производительности базы данных.
Мониторинг результатов SQL-запросов
С помощью SQL-запросов к серверу базы данных также можно выполнять мониторинг сторонних сервисов, которые хранят и обновляют в ней свои параметры. В случае, если значение параметра выйдет за допустимые пределы, программа оповестит об этом администратора.
Мониторинг бизнес-процессов, вычисление результатов проверок по формуле
Также, с помощью SQL-запросов можно настроить мониторинг бизнес-процессов компании, обрабатывая хранящиеся в базе данных значения и метрики: количество продаж, выручку, затраты и т.д. Проверки с SQL-запросами можно использовать как по одной, так и объединяя их в формулу, получая более сложное значение. Для этих целей в программе реализована Вычисляемая по формуле проверка. К примеру, мы можете создать две проверки для разных баз данных и использовать полученные параметры для вычисления какого-то другого значения по заданной формуле. Например, СУММА_ПРОДАЖ = ПРОДАЖИ * ЦЕНА.
Скачайте бесплатную 30-дневную версию программы мониторинга сети прямо сейчас и попробуйте!
Наборы программ для сисадминов: