Gestion de la journalisation dans MongoDB

MongoDB, comme toute autre base de données, peut échouer lors de l'exécution d'une opération d'écriture. Dans ce cas, nous avons besoin d'une stratégie qui maintiendra l'opération quelque part afin que la base de données puisse reprendre lorsqu'elle sera restaurée.

Dans MongoDB, nous utilisons la journalisation dans laquelle il y a une journalisation en écriture anticipée dans les fichiers journaux sur disque pour garder les données disponibles en cas de panne. Le moteur de stockage WiredTiger peut utiliser des points de contrôle pour fournir une vue cohérente des données sur le disque et permettre à MongoDB de récupérer à partir du dernier point de contrôle, mais uniquement s'il ne s'est pas arrêté de manière inattendue. Sinon, pour les informations qui se sont produites lors du dernier point de contrôle, la journalisation doit avoir été activée pour récupérer ces données.

La procédure pour le processus de récupération est la suivante :la base de données recherchera dans les fichiers de données l'identifiant du dernier point de contrôle, utilisera cet identifiant pour rechercher dans les fichiers journaux l'enregistrement qui lui correspond et puis appliquez les opérations dans les fichiers journaux depuis le dernier point de contrôle.

Comment fonctionne la journalisation dans le moteur de stockage WiredTiger

Pour chaque client qui lance une opération d'écriture, WiredTiger crée un enregistrement de journal composé d'opérations d'écriture internes qui ont été déclenchées par l'écriture initiale. Considérez un document dans une collection qui doit être mis à jour et nous nous attendons à ce que son index soit également modifié. Le WiredTiger créera un enregistrement de journal unique qui intégrera l'opération de mise à jour et les modifications d'index correspondantes.

Cet enregistrement sera stocké dans un tampon en mémoire dont la capacité maximale est de 128 Ko. Le moteur de stockage synchronise ensuite ces enregistrements de journal mis en mémoire tampon sur le disque lorsque l'une des conditions suivantes est remplie :

Une opération d'écriture inclut/implique une préoccupation d'écriture de j :vrai.
WiredTiger crée un nouveau fichier journal après chaque 100 Mo de données.
Après toutes les 100 millisecondes en fonction de storage.journal.commitIntervalMs.
En cas de membres du jeu de répliques :
- Instance d'opérations en attente d'entrées d'oplog, c'est-à-dire des opérations de lecture effectuées dans le cadre de sessions causalement cohérentes et des requêtes d'analyse en avant sur l'oplog.
- Après chaque application par lots des entrées oplog dans le cas des membres secondaires.

En cas d'arrêt brutal de mongod, si des opérations d'écriture étaient en cours, les mises à jour peuvent être perdues même si les enregistrements du journal restent dans les tampons WiredTiger.

Compression des données du journal

Le paramètre par défaut dans MongoDB indique à WiredTiger d'utiliser une compression rapide pour les données du journal. Cela peut être modifié en fonction de l'algorithme de compression souhaité à l'aide du paramètre storage.wiredTiger.engineConfig.journalCompressor. Ces enregistrements de journal ne sont compressés que si leur taille est supérieure à 128 octets, ce qui correspond à la taille minimale d'enregistrement de journal de WiredTiger.

Limiter la taille d'un fichier journal

La taille maximale d'un fichier journal est de 100 Mo et donc si le fichier dépasse cette limite, un nouveau sera créé.

Une fois que le fichier journal a été utilisé pour la récupération ou qu'il existe des fichiers plus anciens que celui qui peut être utilisé pour récupérer du dernier point de contrôle, le WiredTiger les supprime automatiquement.

Pré-allocation

Les fichiers journaux peuvent être pré-alloués avec le moteur de stockage WiredTiger si le processus mongod détermine qu'il est plus efficace de préallouer des fichiers journaux que d'en créer de nouveaux.

Fonctionnement de la journalisation dans le moteur de stockage en mémoire

Le moteur de stockage en mémoire a été déclaré dans le cadre de la disponibilité générale (GA) à partir de la version 3.2.6 de MongoDB Enterprise. Avec ce moteur de stockage, les données sont conservées en mémoire, donc pas de technique de journalisation séparée. S'il y a des opérations d'écriture avec un problème d'écriture (j :vrai), elles seront immédiatement reconnues.

Pour un jeu d'instances dupliquées avec un membre votant utilisant le moteur de stockage en mémoire, il faut définir le writeConcernMajorityJournalDefault sur false. Sinon, si ce paramètre est défini sur true, le jeu de réplicas enregistrera un avertissement de démarrage.

Lorsque cette option est définie sur false, la base de données n'attendra pas que l'écriture w:"majority" soit écrite dans le journal sur disque avant de reconnaître les écritures. L'inconvénient de cette approche est qu'avec la majorité des opérations d'écriture peuvent être annulées en cas de perte transitoire (telle qu'un redémarrage ou un crash) d'une majorité de nœuds dans un jeu de réplicas donné.

Si vous utilisez le moteur de stockage MMapv1, la pré-allocation du journal peut être désactivée à l'aide de l'option --nopreallocation lors du démarrage de mongod.

Avec le moteur de stockage WiredTiger, à partir de la version 4.0 de MongoDB, il n'est pas possible de spécifier l'option --nojournal ni même l'option storage.journal.enabled :false pour les membres du jeu de réplicas utilisant le moteur de stockage WiredTiger.

Gérer la journalisation

Désactiver la journalisation

La journalisation ne peut être désactivée que pour les déploiements autonomes et n'est pas recommandée pour les systèmes de production. Pour MongoDB version 4.0 et ultérieure, on ne peut spécifier ni l'option --nojournal ni storage.journal.enabled :false lorsque des membres du jeu de répliques qui utilisent le moteur de stockage WiredTiger sont impliqués.

Pour désactiver la journalisation, démarrez mongod avec l'option de ligne de commande --nojournal.

Surveiller l'état du journal

Pour obtenir les statistiques sur le journal, utilisez la commande db.serverStatus() qui renvoie wiredTiger.log.

Obtenir un accusé de réception

Nous utilisons l'option write concern with j pour obtenir un accusé de réception de validation. {j : vrai}. La journalisation doit être activée dans ce cas sinon l'instance mongod peut produire une erreur.

Si la journalisation est activée, w :"majorité", cela peut impliquer j :vrai.

Pour un jeu de réplicas, lorsque j :vrai, la configuration nécessite uniquement que le primaire écrive dans le journal, quel que soit le problème d'écriture w :.

Cependant, même si j :true est configuré pour un jeu de réplicas, des restaurations peuvent se produire en raison du basculement principal du jeu de réplicas.

Récupération de données d'arrêt inattendu

Tous les fichiers journaux du répertoire du journal sont relus chaque fois que MongoDB redémarre après un plantage avant que le serveur ne soit détecté. Étant donné que cette opération sera enregistrée dans la sortie du journal, il ne sera pas nécessaire d'exécuter --repair.

Modification du compresseur de journal WiredTiger

Le compresseur Snappy est l'algorithme de compression par défaut pour le journal. Cependant, on peut changer cela en fonction de la configuration de l'instance mongod.

Pour une instance mongod autonome :

Définissez le storage.wiredTiger.engineConfig.journalCompressor sur une nouvelle valeur pour le mettre à jour. La méthode la plus appropriée consiste à utiliser le fichier de configuration, mais si vous utilisez les options de ligne de commande, vous devez mettre à jour l'option de ligne de commande --wiredTigerJournalCompressor lors du redémarrage.
Arrêtez l'instance mongod en vous connectant à un shell mongo de l'instance et lancez la commande :db.shutdownServer() ou db.getSiblingDB('admin ).shutdownServer()
Redémarrez l'instance mongod :
1. Si vous utilisez le fichier de configuration, utilisez :mongod -f
2. Si vous utilisez des options de ligne de commande, mettez à jour le wiredTigerJournalCompressor :
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Pour un membre de l'ensemble de répliques :

Arrêtez l'instance mongod :db.shutdownServer() ou db.getSiblingDB(‘admin).shutdownServer()
Apportez les modifications suivantes au fichier de configuration :
1. Définir storage.journal.enabled sur false.
2. Commentez les paramètres de réplication
3. Définissez le paramètre disableLogicalSessionCacheRefresh sur true.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Redémarrez l'instance mongod :
1. Si vous utilisez le fichier de configuration, utilisez :mongod -f
2. Si vous utilisez les options de ligne de commande :incluez l'option --nojournal, supprimez toutes les options de ligne de commande de réplication c'est-à-dire --replSet et définissez le paramètre disableLogicalSessionCacheRefresh sur true
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Arrêter l'instance mongod :

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

Mettez à jour le fichier de configuration pour préparer un redémarrage du membre du jeu de réplicas avec le nouveau compresseur de journal :supprimez le stockage. journal.enabled, décommentez les paramètres de réplication pour le déploiement, supprimez l'option disableLogicalSessionCacheRefresh et enfin supprimez storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Redémarrer l'instance mongod en tant que membre du jeu de répliques

Si vous utilisez le fichier de configuration, utilisez :mongod -f
Si vous utilisez les options de ligne de commande :supprimez les options --nojournal et --wiredTigerJournalCompressor. Incluez les options de ligne de commande de réplication et supprimez le paramètre disableLogicalSessionCacheRefresh.

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Conclusion

Afin que MongoDB garantisse la durabilité d'une opération d'écriture, la journalisation est utilisée dans laquelle les données sont écrites sur le disque à l'avance enregistrement. Autant le moteur de stockage WiredTiger (qui est le plus préféré) peut récupérer les données via les derniers points de contrôle, si MongoDB se ferme de manière inattendue et que la journalisation n'a pas été activée, la récupération de ces données devient impossible. Sinon, si la journalisation est activée, MongoDB peut réappliquer les opérations d'écriture au redémarrage et maintenir un état cohérent.