Exemples de fichiers de configuration YAML pour MongoDB?

La documentation sur les options de configuration de MongoDB répertorie toutes les options disponibles qui peuvent être spécifiées, mais quiconque possède-t-il un ensemble d'exemples de fichiers de configuration entièrement formés, formatés en YAML, pour les instances MongoDB dans différents rôles?

Un ensemble d’exemples pour les rôles communs constituerait un point de départ très utile pour ceux qui partent de zéro ou qui souhaitent tester avec le dernier format de fichier de configuration.

Voici plusieurs exemples de configurations YAML pour Linux (les chemins et options Windows sont légèrement différents), définissant de manière explicite des valeurs par défaut et les paramètres couramment utilisés.

Tout d'abord, une mongodconfiguration autonome avec les paramètres de port, de chemin d'accès et de journal par défaut - il s'agirait du type de configuration utilisé pour les tests locaux, avec quelques extras afin d'afficher le style général:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/data/db/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 127.0.0.1
    port: 27017
    wireObjectCheck : false
    unixDomainSocket: 
        enabled : true

Quelques notes sur cette config:

• En général, vous ne voulez pas que l'objet check-off ( wireObjectCheck: false) soit en production, mais pour un chargement massif de données à des fins de test, cela accélérera un peu les choses et représente un risque minimal dans un tel environnement.
• Cela ne fonctionnerait pas pour la réplication à moins que tous les membres du jeu de réplicas ne se trouvent sur l'adresse IP de bouclage (étant donné qu'il s'agit de la seule liaison spécifiée).

Examinons maintenant un exemple de fichier de configuration pour un membre de jeu de réplicas de production typique avec l'authentification activée et fonctionnant dans le cadre d'un cluster partagé:

storage:
    dbPath: "/data/db"
    directoryPerDB: true
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: 192.0.2.1
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

Quelques notes sur cette configuration:

• Encore une fois, il y a des déclarations explicites de valeurs par défaut et de paramètres implicites (le port est impliqué par clusterRole par exemple), généralement recommandé pour éviter toute confusion.
• La liaison IP est désormais l'adresse IP externe uniquement. Par conséquent, la communication sur l'adresse IP de bouclage échoue, mais la réplication peut fonctionner sur des hôtes distants.
• La valeur par défaut de oplog est de 5% d'espace libre. Il est donc courant sur les gros volumes d'être plus conservateur et de définir explicitement la taille allouée.

Ensuite, un exemple de mongosconfiguration:

sharding:
    configDB: "config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
    autoSplit: true
systemLog:
    destination: file
    path: "/var/log/mongos.log"
processManagement:
    fork: true
net:
    port: 27017
    bindIp: 192.0.2.2
    maxIncomingConnections: 5000
security:
    keyFile: "/data/key/mongos.key"
    authorization: "enabled"

Les seules modifications requises ici sont les suppressions qui ne s'appliquent pas à mongos(car il ne stocke pas de données) et l'ajout de la configDBchaîne, qui doit être identique pour tous les mongosprocessus. J'ai ajouté le paramètre de nombre maximal de connexions à titre d'exemple. Ce n'est pas obligatoire, mais cela peut souvent être une bonne idée pour les plus grands clusters.

Pour compléter le cluster partagé, nous avons un exemple de serveur de configuration, qui est en réalité un sous-ensemble du membre de l'ensemble de réplicas avec quelques modifications mineures:

storage:
    dbPath: "/data/db"
    journal:
        enabled: true
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
processManagement:
    fork: true
net:
    bindIp: 192.0.2.3
    port: 27019
security:
    keyFile: "/data/key/config.key"
    authorization: "enabled"
sharding:
    clusterRole: "configsvr"

Enfin, MongoDB 3.0 (qui n’a pas encore été publié à ce jour) présentera plusieurs nouvelles options, notamment avec l’introduction des nouveaux moteurs de stockage. Par conséquent, voici un exemple sur la façon de configurer le même membre du jeu de réplicas, mais cette fois avec le moteur de stockage WiredTiger et la méthode de compression snappy (valeur par défaut) (remarque: modifié de l'original à cause de SERVER-16266 et exemple ajouté engineConfig):

storage:
    dbPath: "/data/db"
    engine: "wiredTiger"
    wiredTiger:
        engineConfig: 
            cacheSizeGB: 8
        collectionConfig: 
            blockCompressor: snappy        
systemLog:
    destination: file
    path: "/var/log/mongodb.log"
    logAppend: true
    timeStampFormat: iso8601-utc
replication:
    oplogSizeMB: 10240
    replSetName: "rs1"
processManagement:
    fork: true
net:
    bindIp: "192.0.2.1,127.0.0.1"
    port: 27018
security:
    keyFile: "/data/key/rs1.key"
    authorization: "enabled"
sharding:
    clusterRole: "shardsvr"

Enfin, j'ai montré comment lier plusieurs adresses IP à l'aide d'une liste, dans ce cas une adresse IP externe et l'adresse IP de bouclage.