☰

多版本升级后，Zenoss MySQL 数据库备份非常庞大

tag-icon • tag-icon linux mysql zenoss
多版本升级后，Zenoss MySQL 数据库备份非常庞大

上下文：

我们已经运行 Zenoss 2.2 太久了，所以决定升级到当前版本 3.2。我遵循了升级步骤这里，并检查以确保每次增量版本升级后一切都正常。我确保在不确定时重新启动，并验证所有数据库迁移（和升级前的 ZenPack）是否正确应用。一切都正常，除了几个我们不怎么使用的过时的 ZenPack。我们运行 CentOS 5，所以我使用 sourceforge 上提供的旧 rpm 版本进行中间升级，然后使用 yum 进行最后一次“跳跃”到 3.2。出于某种原因，yum 没有安装 3.2 的核心 zenpack，所以我手动安装了，然后一切都正常：zenoss 运行良好，没有问题。嗯...除了一个。

问题：

我们使用 Zenoss 事件数据库的 cron/mysqldump 安排备份。这些备份每天都会进行，通常占用大约 7-800MB 的空间。Zenoss 升级后，这些备份占用了超过 200GB（一个“G”！）的空间，但我还没有看到一个备份完成。要运行备份，我们使用

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

我们有 MySQL 5，因此 --extended-insert 是 mysqldump 的默认参数。Zenoss 是唯一使用数据库的东西（除了 mysql 数据库之外，“events”数据库是唯一存在的数据库），我在转储期间关闭了 Zenoss。我的 ibdata1（我们只有 1 个）文件现在大约有 13GB。我不知道升级之前它有多大。我试过此解决方案删除旧事件详细信息条目。查询一直运行，但之后转储大小像以前一样膨胀。为什么会发生这种情况？我有升级前的备份，我应该恢复吗？

总结：

为什么多版本升级后，我的 Zenoss“事件”数据库转储会增大 1000 倍？

答案1

经过几天的挖掘，我找到了问题所在：InnoDB 损坏。我们的事件数据库确实非常大（我们保留了一年的旧事件，并且有大量的 Windows 计算机报告一些小问题，所以我们有大量的数据），但这不是问题所在。我开始尝试将$ZENHOME\Products\ZenUtils\ZenDeleteEvents.py -n 60事件历史记录缩减到 60 天，但 MySQL 在完成一半后就崩溃了。我查看了 MySQL 日志，发现有大量的 InnoDB 损坏错误。这是最终的解决方案：

  1. 停止 Zenoss
  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 论坛上，我找到了一些有用的信息来帮助我弄清楚到底发生了什么。

相关内容