TL;DR :Vous avez deux options. Utilisez le --smallfiles option de démarrage au démarrage de MongoDB pour limiter la taille des fichiers journaux à 128 Mo, ou désactiver la journalisation à l'aide de --nojournal option. Utilisation de --nojournal en production est généralement une mauvaise idée, et il est souvent logique d'utiliser différents problèmes d'écriture également en développement afin que vous n'ayez pas de code différent en développement et en production.
La réponse longue :Non, la suppression du fichier journal n'est pas sûre. L'idée du journal est la suivante :
Une écriture arrive. Maintenant, pour rendre cette écriture persistante (et la base de données durable), l'écriture doit d'une manière ou d'une autre aller sur le disque.
Malheureusement, les écritures sur le disque prennent des éons par rapport aux écritures sur la RAM, la base de données est donc confrontée à un dilemme :ne pas écrire sur le disque est risqué, car un arrêt inattendu entraînerait une perte de données. Mais écrire sur le disque pour chaque opération d'écriture diminuera tellement les performances de la base de données qu'elle deviendra inutilisable à des fins pratiques.
Désormais, au lieu d'écrire dans les fichiers de données eux-mêmes, et au lieu de le faire pour chaque requête, la base de données ajoutera simplement à un fichier journal où elle stocke toutes les opérations qui n'ont pas encore été validées dans les fichiers de données réels. C'est beaucoup plus rapide, car le fichier est déjà "chaud" car il est lu et écrit tout le temps, et ce n'est qu'un seul fichier, pas un tas de fichiers, et enfin, car il écrit toutes les opérations en attente dans un lot toutes les 100 ms par défaut. Supprimer ce fichier au milieu de quelque chose fait des ravages.
