Tip MySQL: "innodb_file_per_table" ou comment utiliser des fichiers de table séparés pour éviter le manque d’espace disque!!

Bon,
je suis pas très fier de ce que j’ai fait mais je vous relate mes erreurs et comment je suis arrivé à les résoudre pour vous éviter de faire pareil…

Situation

J’installe Mysql sur mon nouveau serveur dédié, monstre de calcul (8 cpu « machin » bridge) et d’espace disque ( 1To). Je configure ma base de données au format  Innodb ( le format qui permet les contraintes externes, etc.); je configure les capacités de mémoire, l’espace disque temporaire;
bref, je crois avoir tout passé en revue…

Puis j’alimente ma base avec des données provenant de réseaux sociaux – autant dire que la volumétrie est importante.

Out of space

Au bout de quelques semaines, je m’aperçoit que le fichier ibdata qui est dans le répertoire de données grossit mais ne rétrécit jamais , y compris lorsque je supprime des tables de plusieurs centaines de GigaOctets.
Finalement j’atteins la taille limite de mon disque et là je suis mal surtout que je dois produire des rapports d’analyse pour avant hier.

L’option de la mort qui tue

C’est là  que je m’aperçoit que par défaut à  l’installation,  MySQL et configuré pour gérer toutes les tables et leurs index dans un seul et même fichier –  le fameux « ibdata » et que ce fichier  est voué a grossir –  jamais à  réduire !
Il aurait fallu utiliser l’option « innodb_file_per_table » dans le fichier de configuration (my.cnf) pour que chaque table utilise son propre fichier de stockage des données et d’index.
Ok, je l’ai pas fait; mais alors comment faire pour rattraper ma bourde ?

Play it like a barbarian

Oui, je dirais qu’il faut y aller « à  la barbare » c’est à  dire faire une réinstallation des bases!
Première chose, faire une sauvegarde complète des bases : 

mysqldump -R -q -p --all-databases > 20120402_mysql_all.sql

Ensuite, arrêter MySQL et supprimer tous les fichiers du répertoire des bases de données( moi, je fais un move sur un support de sauvegarde):

service mysql stop
mv  /home/mysql/* /home/backup/mysql_old_dir

Redémarrer Mysql :

service mysql start

Enfin, restaurer les tables :

mysql -u root  < 20120402_mysql_all.sql

Je vous cache pas qu’il faut aimer avoir des sueurs froides dans le dos pendant quelques longues minutes.

N’hésitez pas à  commenter ce post si vous avez été dans le même cas ! 

Tip MongoDB: dompter MongoDB pour qu’il ne mange pas tout l’espace disque sous ubuntu 64!

Ma bête de course est en train de pleurer à cause d’un manque d’espace disque…
Mais que se passe-t’il donc?
Bon ok, lorsque j’ai fait l’installation d’Ubuntu 64 bits, j’ai paramétré la partition racine à 9 Gb, ce qui est un peu limite.

En utilisant Baobab, le programme de visualisation d’espace disque , je me suis aperçu que le fautif était MongoDB et plus précisément  son  système de journalisation:

Voici donc le moyen pour éviter de consommer de l’espace disque inutilement :

  1. arrêter mongodb :

    sudo service mongodb stop

  • éditer le fichier /etc/mongodb.conf et désactiver la journalisation :

    # Enable journaling, https://www.mongodb.org/display/DOCS/Journaling
    journal=false

  • supprimer les fichier dans le répertoire /var/lib/mongodb
  • redémarrer MongoDB:

    sudo service mongodb stop

Et voilà, votre partition ne va pas être inutilement remplie!

Un autre moyen est de déplacer le répertoire des données de /var/lib/mongodb vers une autre partition (exemple /home/mongodb) Pour cela éditer le fichier /etc/mongodb.conf et modifiez la ligne suivante :

# Where to store the data. dbpath=/var/lib/mongodb

en

# Where to store the data. dbpath=/home/mongodb

puis déplacer les fichiers qui étaient initialement dans /var/lib/mongodb vers le répertoire cible :

sudo cp -rv /var/lib/mongodb /home/mongodb/

Si vous aussi vous avez eu le même problème et que ce post vous a aidé, vous pouvez laisser un commentaire !