Как удержать MySQL от увеличения использования дискового пространства при использовании с puppet-dashboard?

Установка

У нас есть Debian Linux с MySQL v5.1.73 (механизм хранения innoDB) и puppet-dashboard версии 1.2.23. Как вы, наверное, догадались, puppet-dashboard использует MySQL в качестве бэкэнда.

Кроме того, это не должно быть актуальным, но это виртуальная машина VMware на vSphere 5.5.

Эта проблема

Проблема в том, что, несмотря на то, что количество марионеточных узлов и частота выполнения остаются относительно неизменными, дисковое пространство, используемое MySQL, продолжает беспокоящим образом увеличиваться до такой степени, что теперь это становится проблемой.

На следующем графике показана проблема.

Мы создали два задания cron, которые должны позволить освободить дисковое пространство. Они следующие, и оба выполняются ежедневно:

rake RAILS_ENV = production db: raw: optimize
грабли RAILS_ENV = производственные отчеты: обрезка: осиротевшие до = 3 единицы = мес.

Падения, которые вы можете видеть на графике, - это запущенные задания cron, которые занимают больше места, пытаясь освободить место.

Бинарные журналы MySQL не включены. 95% дискового пространства, используемого на этом сервере, находится в каталоге / var / lib / mysql / dashboard_production, в котором хранятся данные MySQL.

У нас раньше была эта проблема с другим приложением (мониторинг Zabbix), и нам приходилось выгружать БД и повторно импортировать, чтобы освободить место. Это был очень болезненный процесс и не очень элегантное решение, но в конечном итоге оно сработало.

Есть ли способ вернуть это дисковое пространство? Что мы можем сделать, чтобы остановить такое поведение?

Редактировать 1

Мы действительно используем innoDB и не используем директиву конфигурации «innodb_file_per_table».

По запросу Феликса вывод команды следующий:

+----------------------+-------------------+-------------+
| 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

Я запустил задачу отчетов: обрезка граблей, и, несмотря на удаление 230000 отчетов, она продолжала занимать больше места ... Поэтому я перейду к другим параметрам.

Решение

После удаления двух третей записей в базе данных высвободилось только 200 МБ дискового пространства, что бессмысленно. Мы закончили тем, что сбросили содержимое и повторно импортировали его, позаботившись о включении "innodb_file_per_table".

Нам просто нужно подождать и посмотреть, исправит ли это решение в долгосрочной перспективе, но, похоже, на данный момент это так.

Я нашел эту статью, которая, кажется, довольно хорошо решает проблему

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

Автор: Ксимена Кардинали

Краткая история - начать удалять отчеты небольшими партиями, а затем освободить место из MySQL.

HOWTO Очистка отчетов и БД марионеток

Если база данных для Puppet Dashboard использует несколько ГБ и увеличивается каждый день, это способ вернуть часть места.

Есть два рейка, которые вы должны выполнять каждый день в рамках ежедневного обслуживания Puppet Dashboard.

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 и количество дней (день), недель (неделя), месяцев (понедельник) и т. Д. В соответствии с вашей системой и ее потребностями.

Остановить входящие отчеты:

cd / путь / к / марионеточной панели

env RAILS_ENV = производственный сценарий / delayed_job -p панель управления -m stop
Начать удалять отчеты небольшими партиями

Продолжайте увеличивать время, в течение которого вы хотите вести отчеты. Причина этого в том, что таблицы Innodb имеют низкую производительность при удалении более 10 тыс. Строк за раз. Если вы попытаетесь удалить несколько сотен тысяч строк, произойдет тайм-аут, и вам все равно придется разбить его на более мелкие удаления. Кроме того, процесс Ruby rake будет использовать, вероятно, всю вашу оперативную память и, вероятно, будет убит ядром до его завершения. Что-то вроде этой прогрессии должно работать для большинства людей, но если у вас есть данные за много месяцев, вы можете начать с месяца или двух из ваших самых ранних записей. В нашем случае мы храним отчеты всего за 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

Определите лучший способ освободить место из MySQL

Есть два метода освобождения места в зависимости от того, как был настроен MySQL. Выполните эту команду, чтобы определить, включен ли "innodb_file_per_table". Если это так, его следует установить в положение «ВКЛ». ПРИМЕЧАНИЕ. Я рекомендую использовать innodb в MySQL для подобных случаев.

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
...

Освободить пространство простым способом

Если MySQL был настроен с innodb_file_per_table и ваша БД Dashoard показывает, что ваши данные находятся в файлах больших таблиц, сделайте следующее:

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 на место. В этом случае мы перешли с 15 ГБ до 708 МБ.

-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

Осваивая пространство трудным путем

Если ваша система не была настроена с помощью innodb_file_per_table или все текущие данные находятся в большом файле ibdata, единственный способ освободить место - стереть всю установку и повторно импортировать все данные. Общий метод должен выглядеть примерно так: сначала настройте innodb_file_per_table, сделайте дамп всех баз данных, затем остановите Mysql, удалите / var / lib / mysql, запустите mysql_install_db, чтобы снова создать / var / lib / mysql, запустите MySQL и, наконец, повторно импортируйте данные. Из-за импорта данных нет необходимости в шагах оптимизации.

Наконец, перезапустите delayed_job:

cd / путь / к / марионеточной панели

env RAILS_ENV = производственный сценарий / delayed_job -p панель инструментов -n 2 -m start
Очистка ежедневных отчетов и обслуживание БД:

Для ежедневной очистки отчетов вы можете создать простой сценарий BASH, который выполняет поиск отчетов по / var / lib / puppet / reports по времени (в нашем случае mtime +14), удаляет их, а затем очищает базу данных с помощью (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