¿Ejemplos de archivos de configuración de YAML para MongoDB?

La documentación de las opciones de configuración de MongoDB enumera todas las opciones disponibles que se pueden especificar, pero ¿alguien tiene un conjunto de archivos de configuración con formato YAML de ejemplo completamente formados para instancias de MongoDB en varios roles?

Un conjunto de ejemplos para los roles comunes sería un punto de partida muy útil para aquellos que comienzan desde cero o buscan probar con el último formato de archivo de configuración.

Aquí hay varios ejemplos de configuraciones de YAML para Linux (las rutas y opciones de Windows son un poco diferentes), esencialmente estableciendo explícitamente algunos valores predeterminados y configuraciones de uso común.

Primero, una mongodconfiguración independiente con el puerto predeterminado, la ruta, la configuración del diario: este sería el tipo de configuración utilizada para las pruebas locales, con algunos extras, así que muestre el estilo general:

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

Algunas notas sobre esta configuración:

• Por lo general, no desea que el objeto se marque ( wireObjectCheck: false) en producción, pero para una carga masiva de datos con fines de prueba, acelerará un poco las cosas y representa un riesgo mínimo en dicho entorno
• Esto no funcionaría para la replicación a menos que todos los miembros del conjunto de réplicas estuvieran en la dirección IP de bucle invertido (ya que este es el único enlace especificado), así que tenga cuidado

Ahora, veamos un archivo de configuración de muestra para un miembro de conjunto de réplica de producción típico con autenticación habilitada y ejecutándose como parte de un clúster fragmentado:

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"

Algunas notas sobre esta configuración:

• Una vez más, hay declaraciones explícitas de valores predeterminados y configuraciones implícitas (el puerto está implícito en clusterRole, por ejemplo), generalmente esto se recomienda para evitar confusiones.
• El enlace de IP ahora es solo la dirección IP externa, por lo que la comunicación en la IP de bucle invertido fallará, pero la replicación puede funcionar en hosts remotos
• El oplog tiene como valor predeterminado el 5% del espacio libre, por lo que es común en grandes volúmenes ser más conservador y establecer explícitamente el tamaño asignado

A continuación, una mongosconfiguración de muestra :

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"

Los únicos cambios requeridos aquí son las eliminaciones que no se aplican a mongos(ya que no almacena datos) y la adición de la configDBcadena, que debe ser idéntica en todos los mongosprocesos. Agregué la configuración de conexiones máximas como ejemplo, no es obligatorio, pero a menudo puede ser una buena idea para grupos más grandes.

Para completar el clúster fragmentado, tenemos un servidor de configuración de muestra, que es realmente un subconjunto del miembro del conjunto de réplica con algunos cambios menores:

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"

Finalmente, MongoDB 3.0 (aún no lanzado al momento de escribir esto) presentará varias opciones nuevas, especialmente con la introducción de los nuevos motores de almacenamiento. Por lo tanto, aquí hay un ejemplo de cómo configurar el mismo miembro del conjunto de réplicas, pero esta vez con el motor de almacenamiento WiredTiger y el método de compresión ágil (el predeterminado) (nota: alterado del original debido a SERVER-16266 y muestra agregada 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"

Como una adición adicional final, mostré cómo vincular múltiples direcciones IP usando una lista, en este caso una IP externa y la IP de bucle invertido.