Мониторинг MySQL репликации в Zabbix

Я активно использую репликацию mysql в своей работе, причем как master-slave, так и master-master. Иногда возникают ошибки, и если за ними не следить, то в определенный момент станет очень грустно, когда окажется, что резервный сервер не имеет актуальную версию базы. Чтобы не грустить по этому поводу, мы настроим мониторинг Mysql репликации с помощью Zabbix.

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

Несколько слов о том, что именно мы будем мониторить. Посмотреть статус репликации можно с помощью простой команды в консоли mysql:

MariaDB [(none)]> show slave status\G;

Нас будут интересовать три параметра:

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

Реализовывать будем так же как и в случае с мониторингом nginx и php-fpm через скрипт и UserParameter. Если у вас репликация master-mastert, то настраиваете мониторинг на обоих серверах.

Я буду настраивать мониторинг на сервере CentOS 7, но в данном случае это не имеет принципиального значения. Настройки будут идентичны практически на любом linux дистрибутиве.

Добавление пользователя mysql

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

Создаем в mysql юзера, у которого будет доступ к информации о репликации:

# mysql -uroot -ppassword

MariaDB [(none)]> CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'parol';
MariaDB [(none)]> GRANT REPLICATION CLIENT ON *.* TO 'zabbix'@'localhost' IDENTIFIED BY 'parol';

Создали учетную запись zabbix с паролем parol и правами replication client. Её мы будем использовать в дальнейшей работе.

Создание скрипта для мониторинга mysql репликации

Теперь создадим скрипт для мониторинга. Скачиваем его отсюда mysql-slave.sh и вставляем содержимое в папку /etc/zabbix/scripts:

# mcedit /etc/zabbix/scripts/mysql-slave.sh
# chown zabbix:zabbix /etc/zabbix/scripts/mysql-slave.sh
# chmod 550 /etc/zabbix/scripts/mysql-slave.sh

Проверяем его работу:

/etc/zabbix/scripts/mysql-slave.sh Master_Host zabbix parol

Скрипт должен вернуть в консоль имя мастера.

Данный скрипт анализирует вывод show slave status\G и парсит 3 необходимых нам значения. Он передает агенту информацию о задержке репликации через параметр Seconds_Behind_Master и анализирует значения Slave_IO_Running и Slave_SQL_Running. Если их значения равны Yes, он передает агенту 1, если там что-то другое то 0.

Настройка zabbix agent

Добавляем новый параметр в zabbix_agentd.conf

# mcedit /etc/zabbix/zabbix_agentd.conf
UserParameter=mysql-slave[*],/etc/zabbix/scripts/mysql-slave.sh "$1" zabbix parol

Сохраняем конфиг и перезапускаем агента:

# systemctl restart zabbix-agent

Настройка мониторинга репликации mysql на zabbix server

Здесь все как обычно. Скачиваем шаблон mysql-slave.xml импортируем его на сервер. Для этого идем в Configuration -> Templates и нажимаем Import:

Выбираем скачанный шаблон и жмем Import:

Дальше отправляемся к списку хостов в Configuration -> Hosts, выбираем нужный хост и назначаем ему новый шаблон:

Жмем Update для применения настроек. Ждем несколько минут и идем проверять поступление новых данных репликации mysql. Открываем Monitoring -> Latest Data, настраиваем фильтр и проверяем значения:

В данном случае мы видим, что значение Seconds Behind Master = 0, отставания от мастера нет. Два других значения равны единице, это значит, что наш скрипт проверки состояния репликации получает статусы Slave_IO_Running и Slave_SQL_Running равные Yes и поэтому возвращает значения 1. То есть наша репликация работает в штатном режиме, все в порядке.

Проверка работы триггеров

Попробуем нарушить работу репликации mysql и проверим работу триггеров. Для этого я просто отключу vpn соединение, по которому доступны сервера. После разрыва связи на slave сервере следующая картинка статуса репликации:

Проверяем данные мониторинга репликации:

Значение Slave_IO_Running сменилось с Yes на Connecting и скрипт проверки вернул значение 0 вместо 1. Этого достаточно, чтобы сработал триггер и пришло оповещение о том, что репликация mysql сервера нарушена:

На почту пришло оповещение:

Восстанавливаем связь между серверами и ждем новой работы триггера и уведомления:

Проверяем Latest Data:

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

Заключение

Для мониторинга состояния репликации mysql мы воспользовались самописным скриптом, который парсит вывод значения show slave status\G и анализирует необходимые нам параметры реплики. На основе этих параметров он передает zabbix агенту необходимые значения для отправки на сервер.

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

Помогла статья? Подписывайся на telegram канал автора

Дополнительные материалы по Zabbix