上下文：
我们跑了太久的Zenoss 2.2，并决定升级到当前版本3.2。 我按照这里的升级步骤进行了检查，并在每次增量版本升级之后确保一切正常。 我确定在不确定时重新启动，并validation所有数据库迁移（和preupgrade ZenPack）都正确应用。 一切正常，除了几个过时的ZenPacks，我们没有太多使用。 我们运行CentOS 5，所以我使用了sourceforge上的旧rpm版本进行中间升级，然后使用yum将最后一个“跳跃”设置为3.2。 由于某些原因yum没有安装3.2的核心zenpacks，所以我手动做了，然后一切都很好：zenoss工作得很好，没有问题。 那么…除了一个。
问题：
我们使用Zenoss事件数据库的cron / mysqldump安排备份。 这些备份每天都会closures，通常占用7-800MB的空间。 在Zenoss升级之后，这些备份占用了200GB以上的空间（尽pipe我还没有看到完成）。 要运行备份，我们正在使用
mysqldump -A | gzip > dump-12-28-2011.sql.gz 我们有MySQL 5，所以–extended-insert是mysqldump的默认参数。 Zenoss是使用数据库的唯一的东西（除了mysql之外，“事件”数据库是唯一存在的），并且在转储过程中我已经closures了Zenoss。 我ibdata1（我们只有1）文件现在是13GB左右。 我不知道升级之前有多大。 我已经试过这个解决scheme来删除旧的事件细节条目。 查询一直运行，但之后的转储就像以前一样。 为什么发生这种情况？ 我有升级之前的备份，我应该恢复吗？
TL; DR：
为什么我的Zenoss“事件”数据库在多版本升级后转储量增加了1000倍？
经过几天的挖掘，我发现了这个问题：InnoDB腐败。 Out事件数据库真的很大（我们保留了一年的旧事件，并且有大量的Windows计算机报告一些小事情，所以我们有很多数据），但这不是问题。 我开始运行$ZENHOME\Products\ZenUtils\ZenDeleteEvents.py -n 60将我们的事件历史logging重新调整为60天，MySQL在完成一半后崩溃。 我查看了MySQL日志，并发现了大量的InnoDB损坏错误。 这是最终的解决scheme：
mysqldump -uzenoss -pzenoss events > dump.sql转储事件数据库出于某种原因，在通过ZenDeleteEvents.py进行修剪之后，转储工作，并且不会变得难以忍受。 zeneventbuild localhost zenoss zenoss events （这些参数对于其他的可能是不同的：语法是zeneventbuild <dbhost> <dbuser> <dbpassword> <dbname> grant super on *.* to 'zenoss'@'localhost' identified by 'zenoss';运行mysql ，然后将grant super on *.* to 'zenoss'@'localhost' identified by 'zenoss'; mysql -uzenoss -pzenoss events < dump.sql恢复事件数据库转储 之后，一切正常，虽然我没有很多的历史事件（我没有使用）。 这个在zenoss论坛的主题是帮助我弄清楚发生了什么。