web-dev-qa-db-fra.com

Exemples de fichiers de configuration YAML pour MongoDB?

La documentation des options de configuration MongoDB répertorie toutes les options disponibles qui peuvent être spécifiées, mais est-ce que quelqu'un a un ensemble d'exemples de fichiers de configuration au format YAML entièrement formés pour les instances MongoDB dans divers rôles?

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

mongodb
33
Adam C

Voici plusieurs exemples de configurations YAML pour Linux (les chemins et options Windows sont un peu différents), définissant essentiellement explicitement certains paramètres par défaut et les paramètres couramment utilisés.

Tout d'abord, un mongod autonome avec le port, le chemin et les paramètres de journal par défaut - ce serait le type de configuration utilisé pour les tests locaux, avec quelques extras, donc montrez 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 règle générale, vous ne voulez pas que l'objet soit coché (wireObjectCheck: false) en production, mais pour un volume important 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 se trouvaient sur l'adresse IP de bouclage (car c'est la seule liaison spécifiée), donc méfiez-vous

Maintenant, regardons un exemple de fichier de configuration pour un membre de jeu de réplicas de production typique avec l'authentification activée et s'exécutant dans le cadre d'un cluster fragmenté:

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:

  • Là encore, 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 cela est recommandé pour éviter toute confusion
  • La liaison IP est désormais l'adresse IP externe uniquement, donc la communication sur l'IP de bouclage va maintenant échouer, mais la réplication peut fonctionner vers des hôtes distants
  • L'oplog par défaut à 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 configuration mongos:

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 des suppressions qui ne s'appliquent pas au mongos (car il ne stocke pas de données) et l'ajout de la chaîne configDB, qui doit être identique sur tous les mongos processus. J'ai ajouté le paramètre de connexions maximales à titre d'exemple, ce n'est pas obligatoire mais peut souvent être une bonne idée pour les clusters plus importants.

Pour compléter le cluster fragmenté, nous avons un exemple de serveur de configuration, qui est vraiment un sous-ensemble du membre du jeu 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 (non encore publié au moment de la rédaction de ce document) introduira plusieurs nouvelles options, en particulier avec l'introduction des nouveaux moteurs de stockage. Par conséquent, voici un exemple de la façon de configurer le même membre de jeu de réplicas, mais cette fois avec le moteur de stockage WiredTiger et (la valeur par défaut) la méthode de compression instantanée (remarque: modifiée par rapport à l'original en raison de SERVER-16266 et ajouté un exemple 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"

Comme dernier bonus supplémentaire, j'ai montré comment lier plusieurs adresses IP à l'aide d'une liste, dans ce cas une IP externe et une IP de bouclage.

47
Adam C