Limiter le stockage des données dans le temps
Les données stockées dans MongoDB peuvent être triées en deux catégories :
- Les données de configurations et des utilisateurs : il s'agit des données du Synchronizer et des paramètres utilisateurs sur l'interface de visualisations ( Listes, Portails, Favoris, ... ),
- Les données d'exploitation de la supervision ( SLA, événements, ... )
La taille des données de configurations et des utilisateurs va s'accroitre lentement dans le temps et restera contenu à l'évolution de votre configuration. En revanche les données d'exploitations de la supervision sont des données qui vont s'accroitre tous les jours, et la croissance sera proportionnelle à votre configuration.
Afin de limiter cette croissance dans le temps, il est possible de limiter la rétention de données d'exploitation afin de ne garder que les données pertinentes pour vous ( Voir MongoDB - Méthode 1 : Ne garder que les données pertinentes. )
Il est également possible de supprimer des anciennes données SLA via l'utilisation d'une commande si vous souhaitez supprimer des données anciennes.
Récupérer l'espace disque
Durant son fonctionnement, MongoDB va ajouter et supprimer des données. Cela peut entraîner une fragmentation de votre base et il peut être nécessaire de récupérer de l'espace disque que MongoDB a acquis, mais dont il ne se sert plus.
Trois méthodes
La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo). Il est possible de surveiller cet écart de consommation, et même la réduire.
| Warning | ||
|---|---|---|
| ||
Avant toute opération, faite un shinken-backup complet du serveur impacté ou avec les options qui permet de sauvegarder données |
Récupérer l'espace disque
Deux méthodes options existent pour le compactage de la base :
- Compactage de la base in-place de la baseFaire une sauvegarde de la base et restauration dans une autre base ( nécessite un arrêt de Shinken pendant les opérations ).
- Migration de MMapV1 vers Wired Tiger ( nécessite un arrêt de Shinken pendant les opérations ).
La première option ne nécessite pas le montage d'une autre base ni de transfert de données.
- C'est globalement plus simple, mais pendant que la base se compacte elle devient indisponible, ce qui peut provoquer un long temps d'indisponibilité.
- De plus, suivant le moteur de base utilisé les contraintes et les résultats sont variables :
- MMapV1:
- le compactage sera efficace en termes de récupération d'espace, mais pendant le compactage, le double du volume de données sera utilisé, il faut donc prévoir assez d'espace disque.
- Wired Tiger: le compactage est moins efficace, le moteur n'arrivant pas à récupérer tout l'espace perdu, mais par contre il se fait in-place sans consommer plus d'espace disque.
Il est fortement recommandé de migrer sur le moteur Wired Tiger, qui permet d'avoir de meilleures performances et un espace disque consommé plus faible ( moins de fragmentation et compression de données ).
- Le script de vérification de la fragmentation permet de donner le moteur de données utilisé : MongoDB - surveillance du taux de fragmentation de la base .
- Par contre, l'opération nécessitera un arrêt de la base mongoDBMongoDB, donc vous devrez planifier une interruption de votre supervision.
Script de suppression des anciennes entrées ⇒ ne garde que X jours en base
Le script shinken-sla-delete-until de suppression vous permet de :
- Nettoyer votre base sans toucher à la configuration de votre module SLA
- Constater le nombre d'enregistrements à supprimer pour atteindre la rétention souhaitée
- Suivre facilement la progression de la suppression des anciennes données
- Pouvoir arrêter la suppression si cela impacte trop les performances, sans avoir à arrêter
- Pouvoir à un ou plusieurs moments
Une fois ces actions réalisées, il est intéressant de configurer le module SLA pour supprimer les anciennes entrées quotidiennement et gérer le volume de données ( paragraphe précédent ).
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Pour l'utilisation de ce script, vous aurez besoin des paramètres suivants :
Date limite de conservation des données SLA.
Toutes les données avant cette date seront supprimée
Le format est JJ-MM-AAAA
Ne peut pas être utilisé avec l'option --nb-day
Nombre de jours sui seront conservés
Ne peut pas être utilisé avec l'option --date
Nombre maximum d'enregistrements qui seront supprimé durant une itération du script.
Le script continuera ses itérations jusqu'a suppression complète des données avant le nombre de jours ou la date indiqué en option.
Force la suppression sans demander confirmation.
A chaque éxécution, le script vous indiquera
Utilisation de l'index de mongo en premier plan.
Cette option va bloquer Mongo durant le temps d'indexation mais les opérations seront beaucoup plus rapide
| Info |
|---|
Le script peut être utilisé avec une date ( option --date ) ou un nombre de jours à conserver ( option --nb-day ) mais il n'est pas possible d'utiliser ces deux options conjointement. |
| Warning |
|---|
Les options --size-batch et --pause-batch peuvent fortement impacté les performances de votre installation. Ne les utilisez pas sans avoir contacté votre support dédié. |
L'option --foreground bloque toute l'installation Mongo. Si cette option est utilisée :
- .