设置
我们有一个使用 MySQL v5.1.73（innoDB 存储引擎）和 puppet-dashboard 版本 1.2.23 设置的 Debian Linux。您可能已经猜到了，puppet-dashboard 使用 MySQL 作为其后端。
此外，它不应该是相关的，但这是 vSphere 5.5 上的 VMware 虚拟机。
问题
问题在于，尽管 puppet 节点的数量和运行频率保持相对相同，但 MySQL 使用的磁盘空间仍在以令人不安的方式不断增加，以至于现在已经成为一个问题。
下图说明了这个问题。
我们已经实施了两个 cron 作业，应该可以释放磁盘空间。它们如下，并且都每天运行：
- 耙 RAILS_ENV=生产数据库：原始：优化
- rake RAILS_ENV=生产报告：修剪：孤立最多=3 单位=星期一
您可以在图中看到的下降是 cron 作业正在运行并占用更多空间以试图释放一些空间。
未启用 MySQL 二进制日志。此服务器上使用的 95% 的磁盘空间位于 /var/lib/mysql/dashboard_production，这是存储 MySQL 数据的目录。
我们之前在使用不同的应用程序（Zabbix 监控）时遇到过这个问题，不得不转储数据库并重新导入以释放空间。这是一个非常痛苦的过程，不是一个非常优雅的解决方案，但它最终奏效了。
有什么办法可以回收这个磁盘空间？我们能做些什么来阻止这种行为？
编辑 1
我们确实在使用 innoDB，并且我们没有使用配置指令“innodb_file_per_table”。
按照 Felix 的要求，命令的输出如下：
+----------------------+-------------------+-------------+
| table_schema | table_name | data_length |
+----------------------+-------------------+-------------+
| dashboard_production | resource_statuses | 39730544640 |
| dashboard_production | metrics | 643825664 |
| dashboard_production | report_logs | 448675840 |
| dashboard_production | timeline_events | 65634304 |
| dashboard_production | reports | 50937856 |
| dashboard_production | resource_events | 38338560 |
| glpidb | glpi_crontasklogs | 21204608 |
| ocsweb | softwares | 8912896 |
| ocsweb | deploy | 5044208 |
| phpipam | logs | 1269584 |
+----------------------+-------------------+-------------+
此外，我将尝试没有提到的“孤立”选项以及其他替代方案的报告：修剪任务，并将保持此问题的更新。
编辑 2
我运行了 reports:prune rake 任务，尽管删除了 230000 份报告，但它继续占用更多空间……因此，我将继续使用其他选项。
解决方案
在删除数据库中三分之二的条目后，它只释放了 200MB 的磁盘空间，这是毫无意义的。我们最终转储了内容并重新导入它，注意启用“innodb_file_per_table”。
我们只需要等待，看看这是否能长期解决解决方案，但目前似乎是这样。
