服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 与puppet-dashboard一起使用时，如何防止MySQL增加磁盘空间使用量？
Intereting Posts
设置PHP生成的JavaScript文件的MIMEtypes 什么是最适合Linux的固态文件系统（SSDFS）？ 为什么CAT5电缆有时候会有绒毛的纤维呢？ 如何自动重新启动logging通知的Opensolaris / OmniOS服务/守护进程，但不是严重错误到syslog？ AWS：使用应用程序生成的会话Cookie的意外的经典ELB行为 无法ping或访问互联网 MS SQL Server 2005复制 以前的IT工作者可能会留下一些后门。 我怎样才能消除它们？ 试图诊断Apache的瓶颈 如何在Linux上查看我的磁盘caching是否被禁用？ 两台内部服务器之间的联网 端口转发IPTABLES公共IP 如何识别Azure App Service中100％CPU使用率的原因？ 从一个CloudFormation堆栈获取信息以在另一个CloudFormation堆栈中使用 Linux软件RAID 10挂1驱动器失败后，mdadm不会让我强行删除有问题的设备

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

设置

我们有一个安装了MySQL v5.1.73（innoDB存储引擎）和puppet-dashboard version 1.2.23的Debian Linux。 正如您可能猜到的那样，puppet-dashboard使用MySQL作为其后端。

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

问题

问题是，尽pipe傀儡节点的数量和运行频率保持不变，但MySQL使用的磁盘空间仍然以令人不安的方式增加，直到现在成为问题。

下图说明了这个问题。

磁盘空间不足

我们已经放置了两个应该允许释放磁盘空间的cron作业。 他们是以下，每天运行：

  • 耙RAILS_ENV =生产分贝：原始：优化
  • 耙RAILS_ENV =生产报告：修剪：孤立upto = 3单位=星期一

你可以在图中看到的滴是运行的cron作业，并占用更多的空间，试图释放一些空间。

MySQL二进制日志未启用。 此服务器上使用的磁盘空间的95％位于存储MySQL数据的目录/ var / lib / mysql / dashboard_production中。

我们之前已经有了一个不同的应用程序（Zabbix监控）的这个问题，不得不转储数据库，并重新导入，以释放空间。 这是一个非常痛苦的过程，不是一个非常优雅的解决scheme，但它最终奏效了。

有什么办法可以回收这个磁盘空间吗？ 我们能做些什么来阻止这种行为？

编辑1

我们的确在使用innoDB，我们没有使用configuration指令“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 | +----------------------+-------------------+-------------+

另外，我会试着报告：修剪任务没有“孤儿”选项，以及其他select，并会保持这个问题更新。

编辑2

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

在这里输入图像说明

解决scheme

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

我们将不得不等待，看是否长期解决了这个问题，但现在看起来就是这样。

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

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

张贴由Ximena Cardinali

小故事开始删除小批量报表，然后从MySQL中回收空间

HOWTO清理木偶报告和数据库

如果Puppet仪表板的数据库每天使用几个GB并且变大，那么这是获得一些空间的一种方法。

您应该每天运行两个耙子作业，作为Puppet仪表板日常维护的一部分。 

 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和天数（天），星期（星期），月（星期一）等，以符合您的系统及其需求。

  1. 停止传入的报告：

    cd / path / to / puppet-dashboard

    env RAILS_ENV =生产脚本/ delayed_job -p dashboard -m stop

  2. 开始小批量删除报告

继续朝着你想要保持报道的时间长度努力。 造成这种情况的原因是Innodb表在一次删除超过10k行时performance不佳。 如果你试图删除几十万行，它会超时，你将不得不把它分解成更小的删除。 另外，Ruby rake进程可能会使用所有的RAM，并可能在内核完成之前被内核杀死。 像这样的进步应该适用于大多数人，但是如果你有很多个月的数据，你可能想从一个或两个最早的logging开始。 在我们的案例中，我们只保留了两周的报告（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的configuration方式，有两种方法可以回收空间。 运行此命令以确定是否启用了“innodb_file_per_table”。 如果是，应该设置为“开”。 注意：我build议在你的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. 回收空间的简单方法

如果MySQLconfiguration了innodb_file_per_table，并且您的Dashoard数据库显示您的数据在大型表文件中，请执行以下操作： 

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

这将根据当前数据创build一个新表并将其复制到位。 如果你正在进行一个列表，而这正在进行，你应该看到这样的事情： 

 -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. 难以回收空间

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

  1. 最后，重新启动delayed_job：

    cd / path / to / puppet-dashboard

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

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

对于每日报告清理，您可以创build一个简单的BASH脚本，按照时间（在我们的例子中为mtime +14）search/ var / lib / puppet / reports上的报告，将其删除，然后清理数据库（upto = 2 unit =周），并将其设置在您的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