Comment puis-je empêcher MySQL d'augmenter constamment son utilisation d'espace disque lorsqu'il est utilisé avec puppet-dashboard?

J'ai trouvé cet article qui semble traiter assez bien du problème

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

publié par Ximena Cardinali

L'histoire courte est de commencer à supprimer les rapports en petits lots, puis de récupérer l'espace de MySQL

COMMENT nettoyer les rapports et la base de données Puppet

Si la base de données de Puppet Dashboard utilise plusieurs Go et devient de plus en plus grande chaque jour, voici une façon de récupérer de l'espace.

Il y a deux tâches rake que vous devriez exécuter tous les jours dans le cadre de la maintenance quotidienne de 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

Vous pouvez modifier le RAILS_ENV et le nombre de jours (jour), semaines (sem), mois (mois), etc. pour correspondre à votre système et à ses besoins.

1. Arrêtez les rapports entrants:

   cd /chemin/vers/puppet-dashboard

   env RAILS_ENV=production script/delayed_job -p dashboard -m stop

2. Commencez à supprimer les rapports par petits lots

Continuez ainsi jusqu'à ce que vous atteigniez la durée pendant laquelle vous souhaitez conserver les rapports. La raison en est que les tables Innodb ont de mauvaises performances lors de la suppression de plus de 10 000 lignes à la fois. Si vous essayez de supprimer quelques centaines de milliers de lignes, le processus expirera et vous devrez le diviser en suppressions plus petites de toute façon. De plus, le processus rake Ruby utilisera probablement tout votre RAM et risque probablement d'être interrompu par le noyau avant de terminer. Une progression de ce type devrait fonctionner pour la plupart des gens, mais si vous avez des données sur plusieurs mois, vous voudrez peut-être commencer par un ou deux mois de vos premiers enregistrements. Dans notre cas, nous ne conservons que les rapports des 2 dernières semaines (14 jours).

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

3. Déterminez la meilleure méthode pour récupérer de l'espace de MySQL

Il existe deux méthodes pour récupérer de l'espace en fonction de la configuration de MySQL. Exécutez cette commande pour déterminer si "innodb_file_per_table" est activé. Il devrait être défini sur "ON" s'il l'est. REMARQUE: Je recommande d'utiliser innodb sur votre MySQL pour des cas comme celui-ci.

mysqladmin variables -u root -p | grep innodb_file_per_table

Vous pouvez également faire une liste de la base de données pour voir s'il existe des fichiers de données plus volumineux. La table la plus susceptible d'être grande est resource_statuses.ibd.

ls -lah /var/lib/mysql/dashboard_production
...
-rw-rw---- 1 mysql mysql      8,9K 08 janv. 12:50 resource_statuses.frm
-rw-rw---- 1 mysql mysql       15G 08 janv. 12:50 resource_statuses.ibd
...

4. Récupérer de l'espace facilement

Si MySQL a été configuré avec innodb_file_per_table et que votre base de données Dashoard montre que vos données sont dans de grands fichiers de table, faites ce qui suit:

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

Cela créera une nouvelle table basée sur les données actuelles et la copiera en place. Si vous faites une liste pendant que cela est en cours, vous devriez voir quelque chose comme ceci:

-rw-rw---- 1 mysql mysql       8,9K 08 janv. 12:50 resource_statuses.frm
-rw-rw---- 1 mysql mysql        15G 08 janv. 12:50 resource_statuses.ibd
-rw-rw---- 1 mysql mysql       8,9K 08 janv. 12:50 #sql-379_415.frm
-rw-rw---- 1 mysql mysql       238M 08 janv. 12:51 #sql-379_415.ibd

Et une fois terminé, il copiera le fichier tmp en place. Dans ce cas, nous sommes passés de 15 Go à 708 Mo.

-rw-rw---- 1 mysql mysql 8,9K 08 janv. 13:01 resource_statuses.frm
-rw-rw---- 1 mysql mysql 708M 08 janv. 13:03 resource_statuses.ibd

5. Récupérer de l'espace difficilement

Si votre système n'a pas été configuré avec innodb_file_per_table ou si toutes les données actuelles résident dans un grand fichier ibdata, la seule façon de récupérer de l'espace est d'effacer toute l'installation et de réimporter toutes les données. La méthode globale devrait être quelque chose comme ceci: Configurez d'abord innodb_file_per_table, exportez toutes les bases de données, puis arrêtez Mysql, supprimez /var/lib/mysql, exécutez mysql_install_db pour recréer /var/lib/mysql, démarrez MySQL, et enfin réimportez les données. Il ne sera pas nécessaire de passer par les étapes d'optimisation en raison de l'importation des données.

6. Enfin, redémarrez le delayed_job :

   cd /chemin/vers/puppet-dashboard

   env RAILS_ENV=production script/delayed_job -p dashboard -n 2 -m start

7. Nettoyage des rapports quotidiens et maintenance de la base de données :

Pour un nettoyage quotidien des rapports, vous pouvez créer un simple script BASH qui recherche les rapports sur /var/lib/puppet/reports par date de modification (mtime +14 dans notre cas), les supprime, puis nettoie la base de données avec (upto=2 unit=sem) et le placer dans votre crontab. Un exemple du script peut être :

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

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