File di configurazione di esempio YAML per MongoDB?

La documentazione sulle opzioni di configurazione di MongoDB elenca tutte le opzioni disponibili che possono essere specificate, ma qualcuno ha un set di file di configurazione in formato YAML di esempio completamente formati per istanze di MongoDB in vari ruoli?

Una serie di esempi per i ruoli comuni sarebbe un punto di partenza molto utile per chi inizia da zero o cerca di provare con il formato di file di configurazione più recente.

Ecco alcuni esempi di configurazioni YAML per Linux (i percorsi e le opzioni di Windows sono leggermente diversi), essenzialmente impostando in modo esplicito alcune impostazioni predefinite e impostazioni comunemente utilizzate.

Innanzitutto, uno standalone mongodcon la porta predefinita, il percorso, le impostazioni del journal - questo sarebbe il tipo di configurazione utilizzata per i test locali, con alcuni extra in modo da mostrare lo stile generale:

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

Alcune note su questa configurazione:

• In genere non si desidera che l'oggetto sia disattivato ( wireObjectCheck: false) in produzione, ma per un carico di dati di massa a scopo di test, accelererà un po 'le cose ed è un rischio minimo in tale ambiente
• Ciò non funzionerebbe per la replica a meno che tutti i membri del set di repliche non si trovassero sull'indirizzo IP di loopback (poiché si tratta dell'unica associazione specificata), quindi fai attenzione

Ora, diamo un'occhiata a un file di configurazione di esempio per un tipico membro del set di repliche di produzione con autenticazione abilitata ed eseguita come parte di un cluster frammentato:

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"

Alcune note su questa configurazione:

• Ancora una volta ci sono dichiarazioni esplicite di valori predefiniti e impostazioni implicite (la porta è implicita da clusterRole per esempio), generalmente si consiglia di evitare confusione
• Il binding IP ora è solo l'indirizzo IP esterno, quindi la comunicazione sull'IP loopback ora fallirà, ma la replica può funzionare su host remoti
• L'oplog viene impostato automaticamente al 5% di spazio libero, quindi è comune su grandi volumi essere più conservativo e impostare esplicitamente la dimensione allocata

Successivamente, una mongosconfigurazione di esempio :

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"

Le uniche modifiche richieste qui sono le rimozioni che non si applicano al mongos(poiché non memorizza i dati) e l'aggiunta della configDBstringa, che deve essere identica su tutti i mongosprocessi. Ho aggiunto l'impostazione di connessioni massime come esempio, non è richiesta ma spesso può essere una buona idea per cluster più grandi.

A completare il cluster frammentato abbiamo un server di configurazione di esempio, che è in realtà un sottoinsieme del membro del set di repliche con alcune piccole modifiche:

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"

Infine, MongoDB 3.0 (non ancora rilasciato al momento della stesura di questo) introdurrà diverse nuove opzioni, in particolare con l'introduzione dei nuovi motori di archiviazione. Pertanto, ecco un esempio di come configurare lo stesso membro del set di repliche, ma questa volta con il motore di archiviazione WiredTiger e il metodo di compressione (predefinito) scattante (nota: modificato dall'originale a causa di SERVER-16266 e campione aggiunto 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"

Come aggiunta di bonus finale, ho mostrato come associare più indirizzi IP usando un elenco, in questo caso un IP esterno e l'IP loopback.