10 параметров MySql, которые следует мониторить в первую очередь

MySql предоставляет огромное количество параметров сервера. Попробую определить 10 must have параметров для мониторинга MySql.

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

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

1. Доступность MySql

Его нужно просматривать в первую очередь! Уверен есть сотни причин по которым сервер БД может упасть и/или стать сверх загруженным. И если Вы сможете оперативно локализовать проблему — можно избежать множество неприятностей. Говоря языком книг этот параметр является необходимым, но не достаточным для обеспечения высокой производительности сервера.

Для того, чтобы убедиться, что сервер работает и доступен, достаточно выполнить:

bash> mysqladmin  -u root -p status

или:

bash> service mysql status

Это нормальная проверка на состояние процесса в Linux. Но она может не дать правильного ответа если сервер MySql перегружен. В случае перегрузки,первый способ не вернет ничего (зависнет), а второй может вернуть pid процесса и тем самым не подать тревожный сигнал.

2. Наличие несекьюрных пользователей.

Есть пользователи с привилегиями ‘%’? Другими словами, есть пользователи которые могут подключаться к базе откуда угодно? Если да то, вероятность того что сервер может подвергнуться атакам выше. Для максимальной безопасности, лучше явно указывать с какого IP адреса разрешены подключения. Для того, чтобы если злоумышленник решит взломать сервер, ему необходимо было бы сначала получить доступ на разрешенный сервер для подключений.

Так же рекомендую проверить пользователей на супер привилегии. Много пользователей с супер привилегиями? Они действительно нужны им?

Учетная запись root по умолчанию обладает супер привилегиями. К сожалению, не для кого не секрет что по умолчанию супер пользователь в MySql называется root. Поэтому будет лучше если завести другого пользователя с никому неизвестным именем и паролем.

CREATE USER 'userUbudabi'@'%’ IDENTIFIED BY 'password';
GRANT ALL ON *.* TO 'userUbudabi'@'%' WITH GRANT OPTION;
DROP USER 'root'@%;
FLUSH PRIVILEGES;

Также нужно убедиться, что для всех пользователей MySql установлен пароль. По умолчанию MySql устанавливается вместе с базой данных test. Даже если у пользователя нет явных привилегий на доступ к этой БД. Он все равно будет видеть её и работать с ней. Ибо на то эта база и создана для тестирования. Поэтому на продакшн серверах лучше всего избегать присутствия базы данных test.

3. Количество отказов в соединении

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

Этот параметр глобальный, его можно посмотреть с помощью

SHOW GLOBAL STATUS LIKE 'aborted_connects';

4. Лог ошибок

Если во время работы у MySql сервера возникают какие либо ошибки — сервер пишет их в туда. Обычно все ошибки которые возникают при работе сервера необходимо просматривать. Если сервереров несколько, то делать это не совсем удобно зато можно написать небольшой bash скрипт, который будет заниматься проверкой логов на всех серверах плюс делать оповещения по почте или по email.

5. Дедлоки

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

SHOW ENGINE INNODB STATUS;

Для более детального ознокамаления — мануал

6. Конфигурация сервера

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

7. Медленные запросы

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

8. Отставания репликации

Почти на всех продакшн серверах используються реплики. Предполагается что отставания по репликации (в идеале) быть не должно. Но если у Вас присутствую регулярные отставания по репликации это повод чтобы начать бить тревогу. Посмотреть отставания на слейве можно с помощью:

SHOW SLAVE STATUS;

9. Значения допустимых коннектов к бд и максимально использованное

Думаю будет не лишним смотреть отношение пик количества использованных коннекшенов к БД и максимально разрешенное. Если эти два показателя похожи, то необходимо предпринять меры. В случае превышения разрешенного лимита новые соединения будут отвергнуты с ошибкой «Too many connections». Узнать текущее соотношение параметров можно выполнив следкющие запросы:

SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'max_used_connections';

10. Среднее количество запросов к БД

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

Если статья оказалась Вам полезной — оставьте коментарий, мне интересно узнать Ваше мнение.

comments powered by Disqus