Проблема с БД Zabbix

[v.goncharov]

Случайно запустил старый zabbix 2.0, он смотрел в ту же базу, в которой у меня работал 2.2

После этого теперь каждые 10 минут в БД сыпятся строки (по 500 за раз):

update graph_discovery set name='{#CONNECTION}.TIMEOUT' where graphid=126306 and parent_graphid=9087;
update graphs_items set drawtype=5,sortorder=1,color='00AA00',yaxisside=0,calc_fnc=2,type=0 where gitemid=436528;
update graphs_items set drawtype=2,sortorder=0,color='0000AA',yaxisside=0,calc_fnc=2,type=0 where gitemid=436529;
update graph_discovery set name='{#CONNECTION}.TIMEOUT' where graphid=126307 and parent_graphid=9087;
update graphs_items set drawtype=5,sortorder=1,color='00AA00',yaxisside=0,calc_fnc=2,type=0 where gitemid=436530;
update graphs_items set drawtype=2,sortorder=0,color='0000AA',yaxisside=0,calc_fnc=2,type=0 where gitemid=436531;

Как это можно поправить, и вообще, что с этим можно сделать? Zabbix тормозит довольно основательно

[rekby]

Я бы восстановил базу из резервной копии и поменял пароли чтобы больше такого не случалось.

Часть информации со счетчиков будет потеряна, но обычно это не критично.

[v.goncharov]

Проблема в том, что заметил через 2 часа только примерно (не ожидал, что сервер запустят, и не ожидал, что в автозагрузке останется)

Восстанавливать из бекапов уже возможности нет - дамп базы только 2 суток вливаться будет (чуть больше 100 Гб весит).

Просто сейчас БД этими апдейтами висит на пределе дискового io, вот и интересует - это теперь надолго, или же он пройдет всеми апдейтами и успокоится. Стоит ли перезапускать заббикс-сервер? (тоже процедура нежелательная - минут 30 простоя будет, и возникает вопрос - поможет ли?)

[rekby]

Именно практического опыта с такими большими базами не имею.

Из общих соображений я бы сделал так:
Вариант 1
если база MyISAM:
DELETE FROM history(historylog и т.п.) WHERE time <= xxx.

Если при это время удаление становитя неприлично долгим - прибить MySQL и переходить к варианту 2.
Если база InnoDB - время точно будет неприлично долгим для соблюдения транзакционности операции и лучше сразу переходить к варианту 2.

Вариант 2:
Историю событий грохнул методом TRUNCATE TABLE .... Zabbix перезапустил.
Или удаление таблицы целиком и потом создание их заново.

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

Так получается:
1. Быстрое решение, освобождает сразу много места и дает время для профилактики такой ситуации в будущем. Оперативный мониторинг работает в штатном режиме и реагирует как надо. Мне кажется это его основное назначение.
2. Есть доступ к старым данным если они зачем-то потребуются
3. Есть запас времени на профилактику проблемы.