Surveillance du taux de fragmentation de la base
Au fur et à mesure des insertions / suppressions d'éléments en base de données, l'espace de stockage peut se retrouver morcelé.
L'enchevêtrement des zones d'espace libre et des zones contenant des données est tel, qu'il devient difficile de réaffecter les zones libres pour y stocker de nouvelles données.
Le ratio espace de stockage utilisé par rapport à la taille effective des données devient plus important, c'est ce qu'on appelle la fragmentation.
Il est possible de surveiller ce taux de fragmentation et même le réduire avec la commande suivante :
Ce script permet d'avoir le calcul de ce taux, avec les volumes utilisés et les volumes sur disque.
Paramètres d'exécution
Sans paramètre, la commande se connecte au serveur MongoDB local.
La commande dispose d'options de connexion à la base MongoDB qui peuvent être utilisés dans les cas suivants : La combinaison des options de connexion à MongoDB peut rapidement devenir complexe ; voici des paramètres adaptés aux cas les plus courants. localhost Nom ou IP du serveur MongoDB. 27017 Port de la base MongoDB. shinken ( ou synchronizer si la commande concerne la base du Synchronizer ) Nom de la base de données à utiliser dans MongoDB. À n'utiliser que si la configuration du module ou du démon a changé la base utilisée par défaut. --- Active la connexion SSH au serveur MongoDB. /var/lib/shinken/.ssh/id_rsa Clé privée SSH pour la connexion au serveur MongoDB. À utiliser en complément de l'option --mongo-use-ssh. shinken Utilisateur à utiliser pour la connexion SSH. À utiliser en complément de l'option --mongo-use-ssh. --- Utilisateur pour l'authentification avec mot de passe. --- Mot de passe de l'utilisateur pour l'authentification avec mot de passe. À utiliser en complément de l'option --mongo-username. Si l'option --mongo-password est utilisée, le mot de passe risque d'être visible dans l'historique des commandes ( via la commande history ). Pour éviter d'exposer le mot de passe, il est possible d'utiliser cette commande uniquement avec l'option --mongo-username. Un prompt interactif apparaîtra alors pour demander le mot de passe. Pour automatiser les commandes dans un script, il est possible de rediriger le contenu d'un fichier contenant le mot de passe ( par exemple : --mongo-password $(cat my_file_with_password) ). --- Active SSL/TLS pour les communications avec la base MongoDB. --- Chemin vers le fichier de l’autorité de certification ( CA ) utilisé pour vérifier le certificat SSL de MongoDB. À utiliser en complément de l'option --mongo-ssl. --- Chemin vers le fichier contenant le certificat SSL du client. À utiliser en complément de l'option --mongo-ssl. --- Mot de passe du certificat SSL du client. À utiliser en complément de l'option --mongo-ssl. --- Chemin vers le fichier CRL ( liste de révocation ) des certificats SSL à rejeter. À utiliser en complément de l'option --mongo-ssl. --- Accepter le certificat SSL de MongoDB même si le nom d’hôte du certificat ne correspond pas à celui du serveur. À utiliser en complément de l'option --mongo-ssl. --- Accepter le certificat SSL de MongoDB même s’il est invalide, par exemple expiré. À utiliser en complément de l'option --mongo-ssl.Options génériques
[root@serveur01 ~] shinken-commande --mongo-host 127.0.0.1 --mongo-port 27017 --mongo-database shinken
Option Valeur par défaut Description Options de connexion SSH
[root@serveur01 ~] shinken-command --mongo-host serveur02 --mongo-port 27017 --mongo-use-ssh --mongo-ssh-key /var/lib/shinken/.ssh/id_rsa --mongo-ssh-user shinken
Option Valeur par défaut Description Options d'authentification
[root@serveur01 ~] shinken-command --mongo-host 127.0.0.1 --mongo-port 27017 --mongo-username shinken --mongo-password shinken
Option Valeur par défaut Description Options SSL/TLS
[root@serveur01 ~] shinken-command --mongo-host serveur02 --mongo-port 27017 --mongo-ssl-ca-file /etc/shinken/certs/mongo/ca.pem --mongo-ssl-pem-key-file /etc/shinken/certs/mongo/client.pem
Option Valeur par défaut Description
Données retournées
La commande va fournir les informations suivantes, pour chacune des bases de données présente sur le serveur :
- Database: le nom de la base
- Disk-usage: la consommation disque de la base
- Data: le volume de données contenu dans la base
- Compression-save: espace disque économisé grâce à la compression de données ( seulement pour Wired Tiger )
- Fragmented: espace non utilisé dû à la fragmentation
- Cet espace peut être réutilisé pour de nouvelles données, à la discrétion du moteur.
- En cas de compactage ou migration, la majeure partie de cet espace pourra être récupéré.
Exécution sur une base avec MMapV1
Sur une base avec MMapV1 l’exécution va donner un résultat suivant :
- Le script va conseiller de migrer de moteur de données, de MMapV1 vers Wired Tiger, en demandant à se référer à la documentation ( voir la page MongoDB - maitriser l'espace utilisé ).
- Le script conseillera une migration de la base de données uniquement si le pourcentage d'espace perdu est > 50%
- Dans ce cas, il conseille de se référer à la documentation ( voir la page MongoDB - maitriser l'espace utilisé ).
- Il fournit l'espace perdu à cause de la fragmentation, qui pourra être récupéré lors d'une migration.
- L'espace sera probablement encore plus grand lors de la migration, car Wired Tiger compresse les données sur disque.
Exécution sur une base avec Wired Tiger
Sur une base avec Wired Tiger, le résultat sera le suivant :
- Le script ne conseillera un compactage de la base de données que si le pourcentage d'espace perdu est > 50%
- Dans ce cas, il conseille de se référer à la documentation ( voir la page MongoDB - maitriser l'espace utilisé ).
- La ligne journal permet de voir la taille du journal de base de Wired Tiger, qui vaut tout le temps 200Mo.