Config 서버
중요
3.4 부터 더 이상 사용되지 않는 미러링된 mongod 인스턴스를 구성 서버(SCCC)로 사용할 수 없습니다. 샤딩된 클러스터를 3.4로 업그레이드하기 전에, 설정 서버를 SCCC에서 CSRS로 변환해야 합니다.
config 서버를 SCCC에서 CSRS로 변환하려면 MongoDB 3.4 매뉴얼 config 서버를 복제본 세트로 업그레이드하기를 참조하세요.
config 서버는 샤딩된 클러스터의 메타데이터를 저장합니다. 메타데이터는 샤딩된 클러스터 내의 모든 데이터 및 구성 요소에 대한 상태 및 조직을 반영합니다. 메타데이터에는 모든 샤드의 청크 목록과 청크를 정의하는 범위가 포함됩니다.
mongos 인스턴스는 이 데이터를 캐시하고 이를 사용하여 읽기 및 쓰기 작업을 올바른 샤드로 라우팅합니다. mongos은(는) 샤드 추가와 같이 클러스터에 대한 메타데이터 변경이 있을 때 캐시를 업데이트합니다. 샤드는 config 서버에서 청크 메타데이터도 읽습니다.
config 서버는 역할 기반 액세스 제어 또는 클러스터 에 대한 내부 인증 설정과 같은 자체 관리 배포서버에 대한 인증 구성 정보도 저장 합니다.
또한 MongoDB는 config 서버를 사용하여 분산된 잠금을 관리합니다.
각 샤딩된 클러스터에는 자체 config 서버가 있어야 합니다. 서로 다른 샤딩된 클러스터에 동일한 config 서버를 사용하지 않아야 합니다.
경고
config 서버에서 관리 작업을 수행하면 샤딩된 클러스터의 성능 및 가용성에 상당한 영향을 미칠 수 있습니다. 영향을 받는 config 서버 수에 따라 cluster가 일정 기간 읽기 전용 또는 오프라인 상태일 수 있습니다.
복제본 세트 config 서버.
버전 3.4에서 변경됨.
샤딩된 클러스터의 구성 서버는 복제본 세트(CSRS)로 배포될 수 있습니다. 구성 서버에 복제본 세트를 사용하면 구성 데이터에 대한 표준 복제본 세트 읽기 및 쓰기 프로토콜을 활용할 수 있으므로 구성 서버 전체에서 일관성이 향상됩니다. 또한, 구성 서버에 복제본 세트를 사용하면 복제본 세트에 최대 50명의 구성원이 있을 수 있으므로 샤딩된 클러스터에 3개 이상의 구성 서버를 보유할 수 있습니다. 구성 서버를 복제본 세트로 배포하려면 구성 서버에서 WiredTiger 스토리지 엔진을실행해야 합니다.
config 서버에 사용할 경우 복제본 세트 구성에 다음과 같은 제한이 적용됩니다.
중재자가 없어야 합니다.
지연된 멤버가 없어야 합니다.
인덱스를 작성해야 합니다(예:
members[n].buildIndexes설정이 false로 설정된 노드가 없어야 합니다).
config 서버에서 읽기 및 쓰기 작업
config 서버에 admin 데이터베이스 및 config 데이터베이스가 있습니다.
구성 서버에 쓰기
admin 데이터베이스에는 인증 및 권한 부여와 관련된 컬렉션과 내부 사용을 위한 다른 시스템* 컬렉션이 포함되어 있습니다.
구성 데이터베이스에는 샤딩된 클러스터 메타데이터가 포함된 컬렉션이 포함되어 있습니다. 청크 마이그레이션 또는 청크 분할 후와 같이 메타데이터가 변경되면 MongoDB는 구성 데이터베이스에 데이터를 씁니다.
사용자는 정상적인 운영 또는 유지 관리 과정에서 config 데이터베이스에 직접 쓰지 않아야 합니다.
config 서버에 쓸 때 MongoDB는 "majority"의 쓰기 고려를 사용합니다.
config 서버에서 읽기
MongoDB는 인증 및 권한 부여 데이터 및 기타 내부 사용을 위해 admin 데이터베이스에서 읽습니다.
MongoDB는 mongos 가 시작될 때 또는 청크 마이그레이션 후와 같이 메타데이터가 변경된 후 config 데이터베이스에서 읽습니다. 샤드는 config 서버에서 청크 메타데이터도 읽습니다.
복제본 세트 구성 서버에서 읽을 때 MongoDB는 "majority"의 읽기 문제 수준을 사용합니다 .
config 서버 가용성
config 서버 복제본 세트가 프라이머리를 잃게 돼 프라이머리를 선택할 수 없게 되면 cluster의 메타데이터는 읽기 전용이 됩니다. 샤드에서의 데이터 읽기 및 쓰기는 가능하나, 복제본 세트가 프라이머리를 선택할 수 있을 때까지 청크 마이그레이션이나 청크 분할은 발생하지 않습니다.
샤딩된 클러스터에서 mongod 및 mongos 인스턴스는 샤딩된 클러스터의 복제본 세트를 모니터링합니다 (예: 샤드 복제본 세트, 구성 서버 복제본 세트).
모든 config 서버를 사용할 수 없게 되면 클러스터가 작동하지 않을 수 있습니다. config 서버를 사용할 수 있고 손상되지 않은 상태로 유지하려면 config 서버의 백업이 중요합니다. config 서버의 데이터는 클러스터에 저장된 데이터에 비해 작으며 config 서버의 활동 로드는 상대적으로 낮습니다.
자세한 내용은 사용할 수 없게되는 config 서버 복제본 세트 멤버를 참조하세요.
샤딩된 클러스터 메타데이터
구성 서버는 구성 데이터베이스에 메타데이터를 저장합니다.
중요
config 서버에서 유지 관리를 수행하기 전에 항상 config 데이터베이스를 백업하세요.
config 데이터베이스에 액세스하려면 mongosh에서 다음 명령을 실행하세요.
use config
일반적으로 config 데이터베이스의 콘텐츠를 직접 편집하지 않아야 합니다. config 데이터베이스에는 다음 컬렉션이 포함되어 있습니다.
이러한 컬렉션과 해당 샤딩된 클러스터이 클러스터에서 수행하는 역할에 대한 자세한 내용은 config 데이터베이스를 참조하세요. 메타데이터 읽기 및 업데이트에 대한 자세한 내용은 Config 서버에서 읽기 및 쓰기 작업을 참조하세요.
샤딩된 클러스터 보안
자체 관리형 내부/멤버십 인증을 사용하여 클러스터 내 보안을 시행하고 권한이 없는 클러스터 구성 요소가 클러스터에 액세스하지 못하도록 합니다. 내부 인증을 시행하려면 클러스터의 각 mongod를 적절한 보안 설정으로 시작해야 합니다.
MongoDB 5.3부터는 SCRAM-SHA-1을 클러스터 내 인증에 사용할 수 없습니다. SCRAM-SHA-256만 지원됩니다.
이전 MongoDB 버전에서는 SCRAM이 명시적으로 활성화되어 있지 않더라도 SCRAM-SHA-1과 SCRAM-SHA-256을 모두 클러스터 내 인증에 사용할 수 있습니다.
자체 관리형 샤딩된 클러스터 배포에 대한 튜토리얼은 키파일 인증을 사용하여 클러스터 배포하기를 참조하세요.