Как я сохраняю MySQL от когда-либо увеличения, это - использование дискового пространства при использовании с марионеточной панелью инструментов?
Установка
Нам настраивали Linux Debian с MySQL v5.1.73 (innoDB механизм устройства хранения данных) и версия 1.2.23 марионеточной панели инструментов. Как Вы, вероятно, предположили, марионеточная панель инструментов использует MySQL в качестве своего бэкенда.
Кроме того, это не должно быть релевантно, но это виртуальная машина VMware на vSphere 5.5.
Проблема
Проблема состоит в том, что, несмотря на количество марионеточных узлов и выполненной частоты, остающейся такой же относительно, дисковое пространство, используемое MySQL, продолжает увеличиваться тревожащим способом до такой степени, когда, это теперь становится проблемой.
Следующий график иллюстрирует проблему.
Мы поместили на месте два задания крона, которые должны позволить дисковому пространству быть освобожденным. Они следующие и оба выполняемых ежедневно:
- обстреляйте RAILS_ENV=production db:raw:optimize
- обстреляйте RAILS_ENV=production reports:prune:orphaned upto=3 unit=mon
Отбрасывания, которые Вы видите в графике, являются выполнением заданий крона и съедением больше пространства, пытающегося освободить некоторое пространство.
Двоичные журналы MySQL не включены. 95% дискового пространства, используемого на этом сервере, расположены в/var/lib/mysql/dashboard_production, который является каталогом, где данные MySQL хранятся.
Мы имели эту проблему прежде с другим приложением (контроль Zabbix) и должны были вывести DB и переимпорт для освобождения пространства. Это было очень болезненным процессом и не очень изящным решением, но это в конечном счете работало.
Есть ли какой-либо способ, которым мы можем исправить это дисковое пространство? Что мы можем сделать эту остановку это поведение?
Редактирование 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 |
+----------------------+-------------------+-------------+
Кроме того, я буду пробовать reports:prune задачу без "осиротевшей" опции, как упомянуто, а также других альтернатив и буду держать этот вопрос в курсе.
Редактирование 2
Я выполнил задачу граблей reports:prune и, несмотря на удаление 230 000 отчетов, это продолжило есть больше пространства... Я буду поэтому идти дальше к другим опциям.
Решение
После удаления двух третей записей в базе данных это только освободило выше на 200 МБ дискового пространства, которое является бессмысленным. Мы закончили тем, что вывели содержание и повторно импортировали его заботящийся для включения "innodb_file_per_table".
Мы должны будем просто ожидать и видеть, фиксирует ли это решение в долгосрочной перспективе, но это, кажется, имеет место в настоящий момент.
I нашел эту статью, которая, кажется, довольно хорошо решает проблему
http://ximunix.blogspot.co.uk/2014/01/howto-cleanup-puppet-reports-and-db.html
, опубликованная Ximena Cardinali
Краткая история - начать удаление отчетов небольшими партиями, а затем освободить место из MySQL.
HOWTO Очистка Puppet Reports и DB
Если база данных для 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 и количество дней (дней), недель (wk ), месяцы (пн) и т. д., чтобы соответствовать вашей системе и ее потребностям.
Остановить входящие отчеты:
cd / path / to / puppet-приборная панель
env RAILS_ENV = производственный скрипт / delayed_job -p dashboard -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 / path / to / puppet-dashboard
env RAILS_ENV = production script / delayed_job -p dashboard - 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