it-swarm.com.de

Beispiel für YAML-Konfigurationsdateien für MongoDB?

In Dokumentation zu MongoDB-Konfigurationsoptionen sind alle verfügbaren Optionen aufgeführt, die angegeben werden können. Verfügt jedoch jemand über eine Reihe vollständig ausgearbeiteter YAML-formatierter 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 vorne anfangen oder mit dem neuesten Konfigurationsdateiformat testen möchten.

33
Adam C

Hier sind 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 ein eigenständiges mongod mit den Standardeinstellungen für Port, Pfad und Journal - dies ist die Art der Konfiguration, die für lokale Tests verwendet wird, mit einigen Extras. Zeigen Sie also 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 Hinweise zu dieser Konfiguration:

  • Im Allgemeinen möchten Sie nicht, dass das Objekt deaktiviert wird (wireObjectCheck: false) in der Produktion, aber für eine große Menge von Daten zu Testzwecken, wird dies die Dinge ein wenig 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). Seien Sie also vorsichtig

Schauen wir uns nun eine Beispielkonfigurationsdatei für ein typisches Produktionsreplikatsatzmitglied 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 Standarderklärungen und implizite Einstellungen (Port wird beispielsweise von clusterRole impliziert). Dies wird im Allgemeinen empfohlen, um Verwirrung zu vermeiden
  • Die IP-Bindung ist jetzt nur die externe IP-Adresse, sodass die Kommunikation auf der Loopback-IP jetzt fehlschlägt, die Replikation jedoch auf Remote-Hosts funktionieren kann
  • Das Oplog verwendet standardmäßig 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 ein Beispiel mongos config:

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 erforderlichen Änderungen sind Entfernungen, die nicht für mongos gelten (da keine Daten gespeichert werden), und das Hinzufügen der Zeichenfolge configDB, die für alle mongos Prozesse. Ich habe die maximale Verbindungseinstellung 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 Beispielkonfigurationsserver, der mit einigen geringfügigen Änderungen eine Teilmenge des Replikatsatzmitglieds ist:

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 des Schreibens 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-Speicher-Engine und der (standardmäßigen) schnellen Komprimierungsmethode (Hinweis: geändert vom Original aufgrund von SERVER-16266 und Beispiel hinzugefügt 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 Bonuszusatz habe ich gezeigt, wie mehrere IP-Adressen mithilfe einer Liste gebunden werden, in diesem Fall eine externe IP und die Loopback-IP.

47
Adam C