Назад | Перейти на главную страницу

Резервные копии базы данных Zenoss MySQL становятся огромными после многоверсионного обновления

Контекст:

Мы слишком долго использовали Zenoss 2.2 и решили, что пора перейти на текущую версию 3.2. Я выполнил шаги обновления Вот, и проверял, что все работает после каждого инкрементного обновления версии. Я обязательно перезапустил, когда не был уверен, и убедился, что все миграции базы данных (и предварительный пакет ZenPack) выполнены правильно. Все работало, за исключением пары устаревших пакетов ZenPack, которые мы все равно мало использовали. Мы запускаем CentOS 5, поэтому я использовал старые версии rpm'd, доступные на sourceforge, для промежуточных обновлений, а затем сделал последний «переход» до 3.2 с помощью yum. По какой-то причине yum не установил основные zenpacks для 3.2, поэтому я сделал это вручную, и тогда все было хорошо: zenoss работал отлично, никаких проблем. Ну ... кроме одного.

Эта проблема:

Мы планируем резервное копирование с помощью cron / mysqldump базы данных событий Zenoss. Эти резервные копии создаются ежедневно и обычно занимают от 7 до 800 МБ дискового пространства. После обновления Zenoss эти резервные копии занимают более 200 ГБ (с буквой G!), Хотя я еще не видел ни одного завершения. Для запуска резервного копирования мы используем 

mysqldump -A | gzip > dump-12-28-2011.sql.gz

У нас MySQL 5, поэтому --extended-insert является параметром по умолчанию для mysqldump. Zenoss - единственное, что использует базу данных (а база данных "events" - единственная, кроме mysql), и я отключил Zenoss на время дампа. Мой файл ibdata1 (у нас только 1) сейчас составляет около 13 ГБ. Я не знаю, насколько он был большим до обновления. я пытался это решение для удаления старых записей сведений о событиях. Запрос выполнялся бесконечно, но после этого размер дампа увеличивался точно так же, как и раньше. Почему это происходит? У меня есть резервные копии, сделанные до обновления, мне вернуться?

TL; DR:

Почему дамп моей базы данных «событий» Zenoss в 1000 раз больше после многоверсионного обновления?

После пары дней копания я понял проблему: повреждение InnoDB. База данных наших событий действительно БЫЛА довольно большой (мы сохраняли годичные старые события, и у нас было множество компьютеров с Windows, сообщающих о мелочах, поэтому у нас было много данных), но проблема не в этом. Я начал бегать $ZENHOME\Products\ZenUtils\ZenDeleteEvents.py -n 60 чтобы сократить нашу историю событий до 60 дней, и MySQL вылетел примерно на полпути. Я просмотрел журналы MySQL и обнаружил множество ошибок повреждения InnoDB. Это было окончательное решение:

  1. Остановить Зеносса
  2. Остановить MySQL
  3. Поместите MySQL в Режим восстановления InnoDB 2
  4. Запустить MySQL
  5. Выгрузить базу событий через mysqldump -uzenoss -pzenoss events > dump.sql По какой-то причине после обрезки через ZenDeleteEvents.py дамп работал и не увеличивался до неуправляемого размера.
  6. Остановить MySQL
  7. Возьмите определения схемы файлов журналов / событий ibdata / innodb из / var / lib / mysql и поместите их где-нибудь для безопасного хранения (на случай, если последующие шаги не сработали)
  8. Выведите MySQL из режима восстановления
  9. Запустить MySQL
  10. Как пользователь zenoss запустите zeneventbuild localhost zenoss zenoss events (эти параметры могут отличаться для других: синтаксис zeneventbuild <dbhost> <dbuser> <dbpassword> <dbname>
  11. Как root, запустите mysql, затем grant super on *.* to 'zenoss'@'localhost' identified by 'zenoss';
  12. Перезагрузите MySQL
  13. Восстановите дамп базы данных событий через mysql -uzenoss -pzenoss events < dump.sql
  14. Снова перезапустите MySQL (возможно, ненужно, но я параноик)
  15. Запустить Zenoss

После этого все заработало, хотя исторических событий у меня было немного (которые я все равно не использовал). Эта ветка на форумах zenoss помог мне понять, что происходит.