Beispiel-YAML-Konfigurationsdateien für MongoDB?

In der Dokumentation zu den MongoDB-Konfigurationsoptionen sind alle verfügbaren Optionen aufgeführt, die angegeben werden können. Verfügt jedoch jemand über eine Reihe vollständig formatierter YAML-Beispielkonfigurationsdateien für MongoDB-Instanzen in verschiedenen Rollen?

Eine Reihe von Beispielen für die allgemeinen Rollen wäre ein sehr nützlicher Ausgangspunkt für diejenigen, die von Grund auf neu beginnen oder mit dem neuesten Konfigurationsdateiformat testen möchten.

Hier einige Beispiele für YAML- Konfigurationen für Linux (Windows-Pfade und -Optionen unterscheiden sich geringfügig), wobei im Wesentlichen einige Standardeinstellungen und häufig verwendete Einstellungen explizit festgelegt werden.

Zunächst wird ein Standalone mongodmit den Standard - Port, Pfad, journal Einstellungen - dies würde die Art der Konfiguration für lokale Tests verwendet werden, mit ein paar Extras zeigen so den allgemeinen Stil:

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

Einige Anmerkungen zu dieser Konfiguration:

• Normalerweise möchten Sie das Objekt nicht wireObjectCheck: falsein der Produktion abhaken lassen ( ), aber für eine große Datenmenge zu Testzwecken wird dies die Dinge etwas beschleunigen und ist in einer solchen Umgebung ein minimales Risiko
• Dies würde für die Replikation nur funktionieren, wenn sich alle Mitglieder des Replikatsatzes auf der Loopback-IP-Adresse befinden (da dies die einzige angegebene Bindung ist)

Sehen wir uns nun eine Beispielkonfigurationsdatei für ein typisches Mitglied eines Produktionsreplikatsatzes an, dessen Authentifizierung aktiviert ist und das als Teil eines Sharded-Clusters ausgeführt wird:

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"

Einige Hinweise zu dieser Konfiguration:

• Auch hier gibt es explizite Deklarationen von Standardeinstellungen und impliziten Einstellungen (der Port wird beispielsweise von clusterRole impliziert). Im Allgemeinen wird dies empfohlen, um Verwirrung zu vermeiden
• Die IP-Bindung ist jetzt nur die externe IP-Adresse, sodass die Kommunikation über die Loopback-IP jetzt fehlschlägt, die Replikation jedoch auf Remotehosts möglich ist
• Der Standardwert für oplog ist 5% des freien Speicherplatzes. Daher ist es bei großen Volumes üblich, konservativer zu sein und die zugewiesene Größe explizit festzulegen

Als nächstes eine Beispielkonfiguration 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"

Die einzigen Änderungen, die hier erforderlich sind, sind Entfernungen, die sich nicht auf die mongos(da keine Daten gespeichert werden) und das Hinzufügen der configDBZeichenfolge beziehen , die bei allen mongosProzessen identisch sein müssen . Ich habe die Einstellung für die maximale Anzahl von Verbindungen als Beispiel hinzugefügt. Sie ist nicht erforderlich, kann aber für größere Cluster oft eine gute Idee sein.

Abgerundet wird der Sharded-Cluster durch einen Beispiel-Konfigurationsserver, der mit einigen geringfügigen Änderungen eine Teilmenge des Replikat-Set-Members darstellt:

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"

Schließlich wird MongoDB 3.0 (zum Zeitpunkt der Veröffentlichung noch nicht veröffentlicht) einige neue Optionen einführen, insbesondere mit der Einführung der neuen Speicher-Engines. Daher finden Sie hier ein Beispiel für die Konfiguration desselben Replikatsatzmitglieds, diesmal jedoch mit der WiredTiger-Speicherengine und der (Standard-) Snappy-Komprimierungsmethode (Anmerkung: geändert vom Original aufgrund von SERVER-16266 und hinzugefügtes Beispiel 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"

Als letzten Bonus habe ich gezeigt, wie man mehrere IP-Adressen mithilfe einer Liste bindet, in diesem Fall eine externe IP und die Loopback-IP.