☰

当与 puppet-dashboard 一起使用时，如何防止 MySQL 增加其磁盘空间使用量？

tag-icon • tag-icon mysql puppet disk-space-utilization puppet-dashboard
当与 puppet-dashboard 一起使用时，如何防止 MySQL 增加其磁盘空间使用量？

设置

我们安装了 Debian Linux，其中安装了 MySQL v5.1.73（innoDB 存储引擎）和 puppet-dashboard 版本 1.2.23。您可能已经猜到了，puppet-dashboard 使用 MySQL 作为其后端。

此外，这不应该相关，但这是 vSphere 5.5 上的 VMware 虚拟机。

问题

问题在于，尽管 Puppet 节点的数量和运行频率保持相对相同，但 MySQL 使用的磁盘空间却以令人不安的方式不断增加，以至于现在成为了一个问题。

下图说明了这个问题。

磁盘空间不足

我们已设置了两个 cron 作业，它们应该可以释放磁盘空间。它们如下，并且每天都会运行：

  • rake RAILS_ENV=生产数据库：原始：优化
  • rake RAILS_ENV=生产报告：prune：孤立最多=3 单位=mon

您可以在图表中看到的下降是 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

我运行了报告：prune rake 任务，尽管删除了 230000 份报告，但它仍然占用更多空间...因此，我将转向其他选项。

在此处输入图片描述

解决方案

删除数据库中三分之二的条目后，只释放了 200MB 的磁盘空间，这毫无意义。我们最终转储了内容并重新导入，并小心启用了“innodb_file_per_table”。

我们只需要拭目以待，看看这是否能从长远角度解决问题，但目前看来确实如此。

答案1

我发现这篇文章似乎很好地解决了这个问题

http://ximunix.blogspot.co.uk/2014/01/howto-cleanup-puppet-reports-and-db.html

由 Ximena Cardinali 发布

简而言之，开始小批量删除报告，然后从 MySQL 回收空间

如何清理 Puppet 报告和数据库

如果 Puppet Dashboard 的数据库使用了数 GB 并且每天都在变大，这是一种恢复部分空间的方法。

作为 Puppet Dashboard 日常维护的一部分，您应该每天运行两个 rake 作业。

cd /usr/share/puppet-dashboard
env RAILS_ENV=production rake reports:prune upto=5 unit=day
env RAILS_ENV=production rake reports:prune:orphaned

您可以更改 RAILS_ENV 和天数（day）、周数（wk）、月数（mon）等以匹配您的系统及其需求。

  1. 停止传入报告：

    cd /路径/到/puppet-dashboard

    env RAILS_ENV=生产脚本/delayed_job -p 仪表板 -m 停止

  2. 开始小批量删除报告

继续努力，直到达到您想要保留报告的时间长度。原因是 Innodb 表在一次删除超过 10k 行时性能不佳。如果您尝试删除几十万行，它将超时，您必须将其分解为较小的删除。此外，Ruby rake 进程可能会使用您所有的 RAM，并且很可能在完成之前被内核杀死。这种进展应该适用于大多数人，但如果您有几个月的数据，您可能希望从最早的一两个月的记录开始。在我们的例子中，我们只保留 2 周的报告（14 天）。

env RAILS_ENV=production rake reports:prune upto=6 unit=mon
env RAILS_ENV=production rake reports:prune upto=4 unit=mon
env RAILS_ENV=production rake reports:prune upto=2 unit=mon
env RAILS_ENV=production rake reports:prune upto=3 unit=wk
env RAILS_ENV=production rake reports:prune upto=1 unit=wk
env RAILS_ENV=production rake reports:prune upto=5 unit=day
  1. 确定从 MySQL 回收空间的最佳方法

根据 MySQL 的配置，有两种方法可以回收空间。运行此命令以确定“innodb_file_per_table”是否已启用。如果已启用，则应将其设置为“ON”。注意：对于这种情况，我建议在 MySQL 上使用 innodb。

mysqladmin variables -u root -p | grep innodb_file_per_table

您还可以列出数据库以查看是否有更大的数据文件。最有可能较大的表是 resource_statuses.ibd。

ls -lah /var/lib/mysql/dashboard_production
...
-rw-rw---- 1 mysql mysql      8.9K Jan 08 12:50 resource_statuses.frm
-rw-rw---- 1 mysql mysql       15G Jan 08 12:50 resource_statuses.ibd
...
  1. 轻松回收空间

如果 MySQL 配置了 innodb_file_per_table，并且您的 Dashoard DB 显示您的数据位于大型表文件中，请执行以下操作：

mysql -u root -p
use puppet_dashboard;
OPTIMIZE TABLE resource_statuses;

这将根据当前数据创建一个新表并将其复制到位。如果您在此过程中执行列表，则应该看到类似以下内容：

-rw-rw---- 1 mysql mysql       8.9K Jan  08 12:50 resource_statuses.frm
-rw-rw---- 1 mysql mysql        15G Jan  08 12:50 resource_statuses.ibd
-rw-rw---- 1 mysql mysql       8.9K Jan  08 12:50 #sql-379_415.frm
-rw-rw---- 1 mysql mysql       238M Jan  08 12:51 #sql-379_415.ibd

完成后，它会将 tmp 文件复制到位。在本例中，我们从 15GB 扩展到 708MB。

-rw-rw---- 1 mysql mysql 8.9K Jan 08 13:01 resource_statuses.frm
-rw-rw---- 1 mysql mysql 708M Jan 08 13:03 resource_statuses.ibd
  1. 艰难地夺回太空

如果您的系统未配置 innodb_file_per_table，或者所有当前数据都驻留在大型 ibdata 文件中，则回收空间的唯一方法是清除整个安装并重新导入所有数据。总体方法应该是这样的：首先配置 innodb_file_per_table，转储所有数据库，然后停止 Mysql，删除 /var/lib/mysql，运行 mysql_install_db 再次创建 /var/lib/mysql，启动 MySQL，最后重新导入数据。由于数据导入，将不需要优化步骤。

  1. 最后，重新启动delayed_job：

    cd /路径/到/puppet-dashboard

    env RAILS_ENV=生产脚本/delayed_job -p 仪表板 -n 2 -m 启动

  2. 每日报告清理和数据库维护：

对于每日报告清理，您可以创建一个简单的 BASH 脚本，该脚本按时间（在我们的例子中是 mtime +14）搜索 /var/lib/puppet/reports 上的报告，删除它们，然后使用（upto=2 unit=wk）清理数据库并将其设置在 crontab 中。脚本示例如下：

#!/bin/bash
REPORTS=`find /var/lib/puppet/reports -type f -mtime +14`
for i in $REPORTS; do rm -f $i; done

cd /usr/share/puppet-dashboardenv RAILS_ENV=production rake reports:prune upto=2 unit=wk

相关内容