Зразки файлів конфігурації YAML для MongoDB?

У документації з параметрами конфігурації MongoDB перераховані всі доступні параметри, які можна вказати, але чи є у когось набір повністю сформованих прикладних конфігураційних файлів у форматі YAML для екземплярів MongoDB в різних ролях?

Набір прикладів для загальних ролей буде дуже корисною відправною точкою для тих, хто починає з нуля, або шукає тестування в останньому форматі файлу конфігурації.

Ось декілька прикладів конфігурацій YAML для Linux (шляхи та параметри Windows трохи відрізняються), по суті явно встановлюючи деякі типові та загальновживані налаштування.

По-перше, автономний mongodпорт з портом за замовчуванням, контуром, налаштуваннями журналу - це був би тип конфігурації, що використовується для локального тестування, з кількома додатками, що показує загальний стиль

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

Деякі примітки до цієї конфігурації:

• Як правило, ви не хочете, щоб об'єкт перевіряв ( wireObjectCheck: false) у виробництві, але для масового навантаження даних для тестування це трохи пришвидшить ситуацію і є мінімальним ризиком у таких умовах
• Це не працює для реплікації, якщо б усі члени набору реплік не знаходилися на IP-адресі циклічного зворотного зв’язку (оскільки це єдина вказана прив'язка), тому будьте обережні

Тепер давайте подивимося на зразок конфігураційного файлу для типового члена набору виробничих реплік з увімкненою автентифікацією та запущеним у складі стриманого кластеру:

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"

Деякі зауваження щодо цієї конфігурації:

• Знову є явні декларації за замовчуванням та параметри, що маються на увазі (порт мається на увазі, наприклад, clusterRole), зазвичай це рекомендується уникати плутанини
• Прив’язка IP-адреси тепер є лише зовнішньою IP-адресою, тому зв’язок із IP-адресою без зворотного зв'язку тепер не вдасться, але реплікація може працювати на віддалені хости
• Оплог за замовчуванням становить 5% вільного простору, тому для великих томів прийнято бути більш консервативним і чітко встановити виділений розмір

Далі зразок 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"

Єдині необхідні зміни тут - це видалення, які не застосовуються до mongos(оскільки він не зберігає дані) та додавання configDBрядка, який повинен бути однаковим у всіх mongosпроцесах. Я додав налаштування максимального з'єднання як приклад, це не потрібно, але часто може бути хорошою ідеєю для великих кластерів.

Заокруглюючи фрагментований кластер, у нас є зразок конфігураційного сервера, який дійсно є підмножиною члена набору реплік з деякими незначними змінами:

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"

Нарешті, MongoDB 3.0 (ще не випущений на момент написання цього запису) введе декілька нових варіантів, особливо з представленням нових двигунів зберігання даних. Отже, ось приклад того, як налаштувати той самий член набору реплік, але цього разу за допомогою двигуна зберігання WiredTiger та методу швидкого стиснення (за замовчуванням) (примітка: змінено на оригінальний через SERVER-16266 та доданий зразок 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"

Як остаточне додаток до бонусу, я показав, як зв’язати кілька IP-адрес за допомогою списку, в даному випадку зовнішнього IP-адреси та IP-адреси із зворотним зв'язком.