SNMP "пинг" vs mysqldump - проблема

[DSV12]

Всем привет!

Zabbix 4.2.0(1), Centos 7.

Мониторим некоторое кол-во железок (UPS) от APC (Schneider Electric) по snmp. Пару раз возникали ситуации (и не только с этим оборудованием), когда устройство на обычный icmp ping отвечало, а реально больше у него ничего не работало - ни web-сервис, ни ssh, ни snmp (решалось перезагрузкой). Поэтому решили сделать что-то типа snmp-ping-а - опрашивать какую-то переменную, а триггер должен срабатывать на nodata() в течении определённого времени. Конкретно опрос делается раз в 60 сек, параметр nodata - 120 сек. Триггер:

{UPSx:upsAdvInputLineVoltage.nodata(120)}=1

И вдруг, в прошедшую субботу (20 апреля, ночью), получаем залп уведомлений. Все пришли практически в одну минуту, парами - проблема-resolved, но при этом все RESOLVED пришли раньше, чем возникли соответствующая ПРОБЛЕМА (отрицательные времена, это уже обсуждалось). Время прибытия уведомлений - 3:02. Чешем в затылке, смотрим логи - непонятно. И сегодня (24 апреля) ночью всё повторяется один-в-один - опять пачка уведомлений, на каждый UPS (всего их шесть), все парами и во всех парах RESOLVED раньше, чем ПРОБЛЕМА. И время то же: 3:02. Балин, да что же это такое? Понятно, что проблемы не в ups-ах, не в сетевитости, а где-то на стороне zabbix-сервера.

Лезу разбираться уже понастойчивее - и вот же оно, событие, чётко коррелирующее по времени и дням недели (это на zabbix-сервере) с рассылкой уведомлений о какбэ проблемах:

# crontab -l
0 3 * * 3,6 /root/backups/backup-db.sh

# cat backups/backup-db.sh
#!/bin/bash
now=$(date +"%d-%m-%Y-%H-%M")
mysqldump -u root zabbix | gzip -6 > /root/backups/mysql/zabbix-bak-$now.sql.gz

Т.е., запуск mysqldump (+gzip) приводит к тому, что срабатывает триггер на nodata() по snmp. Почему? Дамп блокирует базу и из-за этого возникает nodata()? Или что? Gzip однопоточный (сервер четырёхядерный), так что не должен вроде совсем задушить по cpu. Можно, конечно, попробовать вместо gzip-а пустить многопоточную альтернативу - pigz, но, мне кажется, проблема скорее в mysqldump-е. Кстати, время создания бэкапа как раз 3:02 в обоих случаях (время вообще варъируется от 3:01 до 3:06, но snmp "ping" у нас начал работать только на прошлой неделе, в четверг, 18 апреля, так что попали под mysqldump только два последних случая с временем 3:02).

У кого какие мысли будут по поводу?

[DSV12]

Всем привет!

Zabbix 4.2.0(1), Centos 7.
...
Т.е., запуск mysqldump (+gzip) приводит к тому, что срабатывает триггер на nodata() по snmp. Почему? Дамп блокирует базу и из-за этого возникает nodata()?
...
У кого какие мысли будут по поводу?

Спрашивали? Отвечаем . Дело действительно было в механизме работы mysqldump - такой вариант дампа блокирует работу базы при работе "на горячую", что и приводит к nodata().

Решением был переход на неблокирующий дамп: Percona XtraBackup for MySQL Databases.

Достоинства:
1. Работает как заявлено (на движке InnoDB), в случае MyISAM: "If your databases are using the MyISAM storage engine, you can still use XtraBackup but the database will be locked for a short period towards the end of the backup".

Недостатки по сравнению с mysqldump:
1. Работает заметно медленнее, дамп выполняется в несколько раз дольше.
2. Размер дампа примерно в пять раз больше (оба сжаты gzip-ом). Причина в том, что mysqldump делает т.н. логический дамп (sql-операторы, выполнение которых восстанавливает базу - текст, хорошо жмётся), а xtrabackup делает физический дамп.

Вот bash-скрипт (без подробностей), которым я теперь делаю backup, не нарываясь на nodata():

innobackupex --no-timestamp $BASEDIR/$NOW - собственно бэкап
innobackupex --apply-log $BASEDIR/$NOW - делаем бэкап консистентным
tar -czf $BASEDIR/$BACKUP.tgz --remove-files -C $BASEDIR/$NOW/ . - затариваем с gzip-ом.

У innobackupex есть собственный механизм компрессии, ключик --compress, но на сжатый дамп нельзя накатывать логи ( --apply-log ).