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 in-place de la base
- Faire une sauvegarde de la base et restauration dans une autre base
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é.
- Par contre, l'opération nécessitera un arrêt de la base mongoDB, donc vous devrez planifier une interruption de votre supervision.
Script de suppression des anciennes entrées ⇒ ne garde que X jours en base
Pour l'utilisation de ce script, vous aurez besoin des paramètres suivants :
| Option courte | Option longue | Description | Valeur par défaut |
|---|---|---|---|
| -d | --date | 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 | N/A |
| -n | --nb-day | Nombre de jours sui seront conservés Ne peut pas être utilisé avec l'option --date | N/A |
| -u | --url | Nom d'hôte ou adresse de la machine hébergeant la base de données SLA Mongo | localhost |
| -s | --size-batch | 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. | 1000 |
| -p | --pause-batch | Temps de pause entre deux itérations afin de ne pas bloquer Mongo. | 1 |
| -f | --force | Force la suppression sans demander confirmation. A chaque éxécution, le script vous indiquera | Faux (non utilisé) |
| -F | --foreground | 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 | Faux (non utilisé) |
| 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é. |
| Warning |
|---|
L'option --foreground bloque toute l'installation Mongo. Si cette option est utilisée :
|