Docs Menu
Docs Home
/
MongoDB 매뉴얼
/
자체 관리 배포서버
/
관리
/
구성 및 유지 관리

자체 관리형 배포서버를 위한 런타임 데이터베이스 구성

이 페이지의 내용

  • 데이터베이스 구성
  • 보안 고려 사항
  • 복제 및 샤딩 구성
  • 동일한 시스템에서 여러 데이터베이스 인스턴스 실행
  • 진단 구성

명령줄과 구성 파일 인터페이스는 MongoDB 관리자가 데이터베이스 시스템의 작동을 제어할 수 있는 다양한 옵션과 설정을 제공합니다. 이 문서에서는 일반적인 구성에 대한 개요와 일반적인 사용 사례에 대한 권장사항 구성의 예시를 제공합니다.

두 인터페이스 모두 동일한 컬렉션 옵션 및 설정에 대한 액세스를 제공하지만, 이 문서에서는 주로 구성 파일 인터페이스를 사용합니다.

Linux 또는 macOS에 MongoDB를 패키지로 설치하는 경우, 이 기본 구성 파일을 사용하는 초기화 스크립트도 함께 제공됩니다. 이 초기화 스크립트는 다음과 같은 방식으로 이러한 플랫폼에서 mongod를 시작하는 데 사용할 수 있습니다:

  • systemd init 시스템(systemctl 명령)을 사용하는 Linux 시스템의 경우:

    sudo systemctl start mongod

  • SystemV init 시스템(service 명령)을 사용하는 Linux 시스템의 경우:

    sudo service mongod start

  • macOS에서는 brew 패키지 관리자를 사용하여 다음을 수행합니다.

    brew services start mongodb-community@5.0

TGZ 또는 ZIP 파일을 사용하여 MongoDB를 설치한 경우 자체 구성 파일을 생성해야 합니다. 기본 구성 예시는 이 문서의 뒷부분에서 확인할 수 있습니다. 구성 파일을 만든 후에는 --config 또는 -f 옵션을 mongod에 사용하여 이 구성 파일로 MongoDB 인스턴스를 시작할 수 있습니다. 예를 들어 Linux의 경우는 다음과 같습니다.

mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf

데이터베이스 인스턴스 구성을 제어하려면 시스템의 mongod.conf 파일 값을 수정합니다.

데이터베이스 구성

다음 기본 구성을 고려하세요:

processManagement:
   fork: true
net:
   bindIp: localhost
   port: 27017
storage:
   dbPath: /var/lib/mongo
systemLog:
   destination: file
   path: "/var/log/mongodb/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true

대부분의 독립형 서버의 경우 이는 기본 구성으로 충분합니다. 여기에는 몇 가지 가정이 있지만 다음 설명을 고려하는 것이 좋습니다.

  • fork는 true이며, 데몬 모드를 활성화하여 mongod를 분리 ('forks')합니다. 현재 세션의 MongoDB를 사용하며 데이터베이스를 일반 서버처럼 실행할 수 있습니다.

  • bindIp는 localhost로, 서버가 로컬 호스트 IP에서 발생한 요청만을 수신하도록 강제합니다. 시스템 네트워크 필터링에서 제공하는 액세스 제어를 통해 애플리케이션 수준 시스템에서 액세스할 수 있는 보안 인터페이스만을 바인딩합니다(예: '방화벽').

  • port는 27017로, 이는 데이터베이스 인스턴스에 대한 기본 MongoDB 포트입니다. MongoDB는 모든 포트에 바인딩할 수 있습니다. 네트워크 필터링 도구를 사용하여 포트를 기준으로 액세스를 필터링할 수도 있습니다.

    참고

    UNIX와 같은 시스템에서 1024보다 낮은 포트에 프로세스를 연결하려면 수퍼유저 권한이 필요합니다.

  • quiet는 true입니다. 이렇게 하면 출력/로그 파일에서 가장 중요한 항목을 제외한 모든 항목이 비활성화되며, 프로덕션 시스템에는 권장되지 않습니다. 이 옵션을 설정하면 setParameter을 사용하여 런타임 중에 이 설정을 수정할 수 있습니다.

  • dbPath는 /var/lib/mongo로, MongoDB가 데이터 파일을 저장할 위치를 지정합니다.

    yum 또는 apt와 같은 패키지 관리자를 사용하여 Linux에서 MongoDB를 설치한 경우, MongoDB 설치와 함께 제공된 /etc/mongod.conf 파일은 Linux 배포판에 따라 다음 기본값 dbPath을 설정합니다.

    플랫폼
    패키지 관리자
    기본값 dbPath
    RHL/CentOS 및 아마존
    yum
    /var/lib/mongo
    SUSE
    zypper
    /var/lib/mongo
    우분투 및 데비안
    apt
    /var/lib/mongodb
    macOS
    brew
    /usr/local/var/mongodb

    mongod를 실행하는 사용자 계정은 이 디렉토리에 대한 읽기 및 쓰기 권한이 필요합니다.

  • systemLog.path는 /var/log/mongodb/mongod.log로, mongod에서 이곳에 출력을 씁니다. 이 값을 설정하지 않으면 mongod에서 모든 출력을 표준 출력에 씁니다 (예: stdout.)

  • logAppend는 true이므로, 서버 시작 작업 후 mongod가 기존 로그 파일을 덮어쓰지 않도록 합니다.

  • storage.journal.enabled 는 true 이며, 이는 저널링 을 활성화합니다. 저널링은 단일 인스턴스 쓰기 지속성을 보장합니다. mongod 의 64비트 빌드는 기본적으로 저널링을 활성화합니다. 따라서 이 설정은 중복될 수 있습니다.

기본 구성을 고려할 때 이러한 값 중 일부는 중복될 수 있습니다. 그러나 많은 상황에서 구성을 명시적으로 나타내면 전반적인 시스템 이해도가 높아집니다.

보안 고려 사항

다음 구성 옵션은 mongod 인스턴스에 대한 액세스를 제한하는 데 유용합니다.

net:
   bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
security:
   authorization: enabled
net.bindIp

이 예시에서는 bindIp 옵션에 4개의 값을 제공합니다.

  • localhost- localhost 인터페이스

  • 10.8.0.10, 일반적으로 로컬 네트워크 및 VPN 인터페이스에 사용되는 개인 IP 주소입니다.

  • 192.168.4.24, 일반적으로 로컬 네트워크에 사용되는 개인 네트워크 인터페이스입니다.

  • /tmp/mongod.sock, Unix 도메인 소켓 경로입니다.

프로덕션 MongoDB 인스턴스는 여러 데이터베이스 서버에서 액세스할 수 있어야 하므로 애플리케이션 서버에서 액세스할 수 있는 여러 인터페이스에 MongoDB를 바인딩하는 것이 중요합니다. 동시에 이러한 인터페이스를 네트워크 계층에서 제어되고 보호되는 인터페이스로 제한하는 것도 중요합니다.

security.authorization
이 옵션을 true로 설정하면 MongoDB 내에서 권한 부여 시스템이 활성화됩니다. 이를 활성화한 경우 사용자 자격 증명을 생성하려면 처음으로 localhost 인터페이스를 통해 연결하여 로그인해야 합니다.

팁

다음도 참조하세요.

보안

복제 및 샤딩 구성

복제 구성

복제본 세트 설정은 간단합니다. replSetName에 세트의 모든 멤버 간에 일관된 값만 있으면 됩니다. 다음 사항을 고려하세요.

replication:
   replSetName: set0

설명적 이름을 세트에 사용합니다. 구성이 완료되면 mongosh를 사용하여 복제본 세트에 호스트를 추가합니다.

팁

다음도 참조하세요.

복제본 세트 재구성

keyfiles를 사용하여 복제본 세트에 대한 인증을 활성화하려면 다음 keyFile 옵션 [1]을 추가합니다.

security:
   keyFile: /srv/mongodb/keyfile

keyFile을 설정하면 인증이 활성화되고 복제본 세트 멤버가 서로 인증할 때 사용할 키 파일을 지정합니다.

팁

다음도 참조하세요.

복제본 세트 보안 섹션에서 복제본 세트를 사용한 인증 설정에 대한 정보를 확인할 수 있습니다.

MongoDB에서의 복제와 일반적인 복제본 세트 구성에 대한 자세한 내용은 복제 문서를 참조하세요.

[1] 샤딩된 클러스터와 복제본 세트는 키 파일 대신 x.509를 사용하여 멤버십을 확인할 수 있습니다. 자세한 내용은 x.509를 참조하세요.

샤딩 구성

샤딩에는 config 서버 및 샤드에 대해 다른 mongod 구성을 가진 mongod 인스턴스가 필요합니다. config 서버는 클러스터의 메타데이터를 저장하고, 샤드는 데이터를 저장합니다.

config 서버 mongod 인스턴스를 구성하려면 구성 파일에서 sharding.clusterRole 설정에 대해 configsvr을 지정합니다.

참고

Config 서버는 복제본 세트로 배포해야 합니다.

 sharding:
    clusterRole: configsvr
 net:
    bindIp: 10.8.0.12
    port: 27001
replication:
    replSetName: csRS

config 서버를 복제본 세트로 배포하려면 config 서버에서 WiredTiger 스토리지 엔진을 실행해야 합니다. Initiate 복제본 세트를 만들고 노드를 추가합니다.

샤드 mongod 인스턴스를 구성하려면 sharding.clusterRole 설정에 shardsvr를 지정하고, 복제본 세트로 실행 중인 경우 복제본 세트 이름을 지정합니다.

sharding:
   clusterRole: shardsvr
replication:
   replSetName: shardA

복제본 세트로 실행하는 경우, 샤드 복제본 세트를 initiate하고 멤버를 추가합니다.

라우터의 경우(예: mongos, 다음 설정으로 하나 이상의 mongos 프로세스를 구성합니다.

sharding:
   configDB: csRS/10.8.0.12:27001

복제본 세트 이름 뒤에 쉼표로 구분된 목록 형식으로 호스트 이름과 포트를 지정하여 config 서버 복제본 세트의 추가 노드를 지정할 수 있습니다.

팁

다음도 참조하세요.

샤딩 및 클러스터 구성에 대한 자세한 내용은 매뉴얼의 샤딩 섹션을 참조하세요.

동일한 시스템에서 여러 데이터베이스 인스턴스 실행

대부분의 경우 단일 시스템에서 mongod의 여러 인스턴스를 실행하는 것은 권장되지 않습니다. 일부 배포 유형 [2] 및 테스트 목적으로 단일 시스템에서 mongod를 둘 이상 실행해야 할 수도 있습니다.

이 경우 각 인스턴스에 대해 기본 구성을 사용하되 다음 구성 값을 고려하세요:

storage:
   dbPath: /var/lib/mongo/db0/
processManagement:
   pidFilePath: /var/lib/mongo/db0.pid

dbPath 값은 mongod 인스턴스의 데이터 디렉토리 위치를 제어합니다. 각 데이터베이스에 고유하고 레이블이 잘 지정된 데이터 디렉토리가 있는지 확인합니다. pidFilePath는 mongod 프로세스가 프로세스 ID(PID) 파일을 배치하는 위치를 제어합니다. 이는 특정 mongod 파일을 추적하므로 이러한 프로세스를 쉽게 시작하고 중지할 수 있도록 파일이 고유하고 레이블을 잘 지정하는 것이 중요합니다.

이러한 프로세스를 제어하기 위해 필요에 따라 init 스크립트를 추가로 생성하거나 기존 MongoDB 구성 및 초기화 스크립트를 조정합니다.

[2] SSD 또는 기타 고성능 디스크가 있는 단일 테넌트 시스템은 여러 mongod 인스턴스에 대해 허용 가능한 성능 수준을 제공할 수 있습니다. 또한 작은 작업 세트가 포함된 여러 데이터베이스가 단일 시스템에서 적절하게 작동할 수도 있습니다.

진단 구성

다음 구성 옵션은 진단을 위해 다양한 mongod 동작을 제어합니다.

  • {operationProfiling.mode는 데이터베이스 프로파일러 수준을 설정합니다. 프로파일러 자체가 성능에 영향을 미칠 수 있기 때문에 프로파일러는 기본적으로 활성화되지 않습니다. 이 설정이 켜져 있지 않으면 쿼리가 프로파일링되지 않습니다.

  • operationProfiling.slowOpThresholdMs configures the threshold which determines whether a query is "slow" for the purpose of the logging system and the profiler. The default value is 100 milliseconds. Set to a lower value if the logging system and the database profiler do not return useful results or set to a higher value to only log the longest running queries.

    이제 복제본 세트의 세컨더리 멤버가 느린 작업 임곗값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.

    • diagnostic log에 세컨더리 멤버에 대해 기록합니다.

    • applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.

    • 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.

    • 프로파일링 수준에 의존하지 않습니다.

    • slowOpSampleRate의 영향을 받습니다.

    프로파일러는 느린 oplog 항목을 캡처하지 않습니다.

  • systemLog.verbosity는 mongod가 로그에 기록하는 로깅 출력의 양을 제어합니다. 정상적인 로깅 수준에 반영되지 않는 문제가 발생하는 경우에만 이 옵션을 사용합니다.

    systemLog.component.<name>.verbosity 설정을 사용하여 특정 구성 요소의 상세 수준을 지정할 수도 있습니다. 사용 가능한 구성 요소는 component verbosity settings를 참조하세요.

자세한 내용은 데이터베이스 프로파일러 및 MongoDB 성능을 참조하세요.

돌아가기

구성 및 유지 관리

다음

최신 패치 릴리스로 업그레이드