MongoDB 용 샘플 YAML 구성 파일?

MongoDB의 구성 옵션 문서 목록을 모두 지정할 수 있지만 사람이 완전히 형성 예를 YAML는 다양한 역할에서 MongoDB를 인스턴스의 경우 구성 파일 형식의 세트가 않습니다 사용할 수있는 옵션?

공통 역할에 대한 예제 세트는 처음부터 시작하거나 최신 구성 파일 형식으로 테스트하려는 사용자에게 매우 유용한 시작점이 될 것입니다.

다음은 Linux 용 YAML 구성 의 몇 가지 예입니다 (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의 통신은 실패하지만 복제는 원격 호스트로 작동 할 수 있습니다
• oplog는 기본적으로 사용 가능한 공간의 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 스토리지 엔진 및 (기본) snappy 압축 방법 (참고 : SERVER-16266으로 인해 원본에서 변경 되었으며 sample 추가됨 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)을 보여주었습니다.