La base Mongodb
La base Mongodb utilisé est la version 3.0.15. Elle est livrée avec deux moteurs de données:
- MMapv1: utilisé seulement si vous avez une installation initiale de Shinken en V02.06.03 ou antérieur, toutes les installations suivantes utilisent le moteur Wired Tiger
- Wired Tiger: moteur récent et performant, utilisé pour toutes les nouvelles installations de serveurs, présent par défaut pour les serveurs Shinken installés en V02.07.00 ou supérieur
Les points à surveiller
Fragmentation des fichiers de stockage
Pour stocker ses données, MongoDB alloue des pages par défaut de 512 Mo.
- Avec le temps, le stockage de donnée sur disque peut créer de la fragmentation car des données sont supprimés, mais mongoDB ne peut pas forcément utiliser des espaces libérés (si par exemples les entrées à écrire sont plus grandes que celles qui ont été supprimées).
- Il s'agit donc d'un point attention. Nous mettons à disposition :
- Un script pour vérifier cela ( cf MongoDB - surveillance du taux de fragmentation de la base )
- Ainsi que la procédure pour récupérer l'espace fragmenté ( cf MongoDB : maitriser l'espace utilisé )
La taille des logs
Les logs de mongo se trouvent par défaut dans le répertoire /var/log/mongodb/mongo.log
Par défaut, mongoDB ne limite pas la taille de ses logs.
- Il faut donc le mettre en place ( cf MongoDB - rotation des logs ).
Rotation des log
Depuis la version 02.08.02 nous avons ajouter une rotation automatique des log de la base, par défaut la rotation est mensuelle.
Pour les version précédent vous pouvez mettre en place vous même la rotation des log.
=> jouable mais avec une modif dans la conf de toute manière: https://www.percona.com/blog/2018/09/27/automating-mongodb-log-rotation/
Compactage de la base
TODO : Compatage de la base : https://docs.mongodb.com/v3.6/reference/command/compact/#dbcmd.compact + backup restore
Surveillance du taux
Compactage de la base
2 options existent pour le compactage de la base :
- Compactage dans la base
- Faire une sauvegarde la base et restauration dans une autre base
La 1ere option ne nécessite pas le montage d'une autre base ni de transfère de donnée c'est globalement plus simple mais pendant que la base se compacte elle est indisponible ce qui peux provoquer un long temps indisponibilité.
Une autre chose à pendre en compte : depuis la version 02.07.00 nous avons mis à jour la version de Mongo utilisé, nous sommes passé de la version V02.09 à V03.00. La version V03.00 de Mongo utilise par défaut un nouveau moteur de stockage : Wired Tiger, plus performant.
Si votre installation initiale de Shinken est antérieure à la version 02.07.00 il y a de grande chance que vous n'utilisez pas le moteur Wired Tiger mais MMAPv1. Vous pouvez vérifiez avec la commande suivante :
| Code Block |
|---|
mongo shinken --quiet --eval "print(db.serverStatus().storageEngine.name)" |
Si vous n'utilisiez pas le moteur Wired Tiger nous vous conseillons la méthode de transfère de donnée vers une autre base pour utiliser le moteur Wired Tiger dans la nouvelle base.
=> Question: quid du cas où on est en cluster?