Exécutez un serveur de configuration MongoDB sans 3 Go de fichiers journaux

9

Pour une installation MongoDB partagée en production, nous avons besoin de 3 serveurs de configuration. Selon la documentation "le processus mongod du serveur de configuration est assez léger et peut être exécuté sur des machines effectuant d'autres travaux". Cependant, dans la configuration par défaut, ils ont tous activé la journalisation, et avec la préallocation, cela prend 3 Go d'espace disque. Je suppose que le volume réel de données et de transactions d'un serveur de configuration est assez petit, de sorte que cela semble un peu trop.

Existe-t-il un moyen (en toute sécurité!) D'exécuter ces serveurs de configuration avec beaucoup moins d'utilisation du disque pour le journal? Ai-je vraiment besoin de journalisation sur les serveurs de configuration? Puis-je définir une taille de journal plus petite?

replication mongodb sharding journalling Thilo
la source

Réponses:

10

Oui - il existe un moyen de minimiser la taille par défaut des fichiers journaux, sous réserve de quelques mises en garde. Dans la documentation de configuration de MongoDB :

Pour réduire l'impact de la journalisation sur l'utilisation du disque, vous pouvez laisser le journal activé et définir les petits fichiers sur true pour réduire la taille des données et des fichiers journaux.

Voici les smallfilesinformations de configuration:

Définissez sur true pour modifier MongoDB afin d'utiliser une taille de fichier de données par défaut plus petite. Plus précisément, les petits fichiers réduisent la taille initiale des fichiers de données et les limitent à 512 mégaoctets. Le paramètre smallfiles réduit également la taille de chaque fichier journal de 1 gigaoctet à 128 mégaoctets.

Utilisez le paramètre smallfiles si vous disposez d'un grand nombre de bases de données contenant chacune une petite quantité de données. Le paramètre smallfiles peut conduire mongod à créer de nombreux fichiers, ce qui peut affecter les performances des bases de données plus volumineuses.

plateformes
la source
0

Vous pouvez certains membres, de réplication , utiliser la journalisation et d'autres non. [1]

Vous pouvez définir une taille jounrale plus petite en utilisant la ligne de commande "--smallfiles". [2]

Nican
la source
Et est-ce que tout cela est recommandé?
Thilo
MongoDB effectue une pré-allocation avec les fichiers journaux pour éviter de perdre du temps avec. Si vous vous souciez plus de l'espace disque que des performances, c'est une option. Je recommanderais de laisser la journalisation sur toutes les machines, vous ne savez jamais quand et comment un crash peut se produire. Vous ne pouvez jamais être trop en sécurité.
Nican
1
C'est bien sûr une bonne ligne directrice. Mais les esprits curieux veulent savoir si un serveur de configuration a un volume de transactions qui nécessite 3 Go de journaux, et s'il y a un avantage à avoir des journaux à part un temps de démarrage plus rapide après un crash (notez qu'avec 3 serveurs de configuration, il ne devrait pas y avoir être une perte de données, même sans journalisation, non?) Et combien plus rapide de toute façon avec la petite quantité de données de configuration uniquement. Il me semble que les règles ici devraient être différentes pour les nœuds de réplique et les serveurs de configuration. Les docs disent que "ça devrait aller si vous pouvez en récupérer un en une journée" par exemple.
Thilo
0

Vous pouvez démarrer mongod avec l'option --nojournal, mais je serais très certain de vos sauvegardes de serveur de configuration.

gWaldo
la source
1
À quel point dois-je être plus sûr d'avoir trois serveurs de configuration sur trois machines différentes? De plus, quelle est la procédure pour effectuer des sauvegardes du serveur de configuration? Si je ne sauvegarde pas après chaque modification (par exemple, ajout de collection ou événement de partitionnement), je ne peux pas récupérer à partir de ces sauvegardes obsolètes, non?
Thilo