Przykładowe pliki konfiguracyjne YAML dla MongoDB?

Dokumentacja opcji konfiguracji MongoDB zawiera listę wszystkich dostępnych opcji, które można określić, ale czy ktoś ma zestaw w pełni sformatowanych przykładowych plików konfiguracyjnych w formacie YAML dla instancji MongoDB w różnych rolach?

Zestaw przykładów typowych ról byłby bardzo przydatnym punktem wyjścia dla tych, którzy zaczynają od zera lub chcą przetestować przy użyciu najnowszego formatu pliku konfiguracyjnego.

Oto kilka przykładów konfiguracji YAML dla systemu Linux (ścieżki i opcje systemu Windows są nieco inne), w zasadzie jawnie ustawiając niektóre ustawienia domyślne i często używane ustawienia.

Po pierwsze, samodzielny mongodz domyślnym portem, ścieżką, ustawieniami dziennika - byłby to typ konfiguracji używanej do testowania lokalnego, z kilkoma dodatkami, więc pokaż ogólny styl:

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

Kilka uwag na temat tej konfiguracji:

• Zasadniczo nie chcesz, aby obiekt był wyłączony ( wireObjectCheck: false) podczas produkcji, ale w przypadku masowego ładowania danych do celów testowych przyspieszy to trochę i stanowi minimalne ryzyko w takim środowisku
• Nie działałoby to w przypadku replikacji, chyba że wszystkie elementy zestawu replik byłyby pod adresem IP pętli zwrotnej (ponieważ jest to jedyne określone powiązanie), więc uważaj

Teraz spójrzmy na przykładowy plik konfiguracyjny dla typowego członka zestawu replik produkcyjnych z włączonym uwierzytelnianiem i działającym jako część podzielonego klastra:

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"

Kilka uwag na temat tej konfiguracji:

• Ponownie istnieją wyraźne deklaracje domyślnych i domyślnych ustawień (port jest sugerowany na przykład przez klasterRole), ogólnie zaleca się, aby uniknąć pomyłek
• Powiązanie IP jest teraz tylko zewnętrznym adresem IP, więc komunikacja na IP pętli zwrotnej nie powiedzie się, ale replikacja może działać na zdalnych hostach
• Domyślnie oplog wynosi 5% wolnego miejsca, więc na dużych woluminach często zachowuje się bardziej zachowawczo i wyraźnie określa przydzielony rozmiar

Następnie przykładowa mongoskonfiguracja:

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"

Jedyne wymagane zmiany tutaj to usunięcia, które nie dotyczą mongos(ponieważ nie przechowuje danych) oraz dodanie configDBciągu, który musi być identyczny we wszystkich mongosprocesach. Jako przykład dodałem ustawienie maksymalnych połączeń, nie jest ono wymagane, ale często może być dobrym pomysłem w przypadku większych klastrów.

Zaokrąglając podzielony klaster, mamy przykładowy serwer konfiguracji, który jest tak naprawdę podzbiorem elementu zestawu replik z pewnymi drobnymi zmianami:

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"

Wreszcie MongoDB 3.0 (jeszcze nie wydany w chwili pisania tego tekstu) wprowadzi kilka nowych opcji, szczególnie wraz z wprowadzeniem nowych silników pamięci masowej. Dlatego oto przykład konfiguracji tego samego elementu zestawu replik, ale tym razem za pomocą silnika pamięci WiredTiger i (domyślnej) szybkiej metody kompresji (uwaga: zmieniona z oryginalnej z powodu SERVER-16266 i dodana próbka 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"

Jako ostatni dodatek pokazałem, jak powiązać wiele adresów IP za pomocą listy, w tym przypadku zewnętrznego adresu IP i IP sprzężenia zwrotnego.