Config 서버
구성 서버는 샤딩된 클러스터 에 대한 메타데이터 를 저장 합니다. 메타데이터 는 샤딩된 클러스터 내의 모든 데이터 및 구성 요소에 대한 상태 및 조직 을 반영합니다. 메타데이터 에는 모든 샤드 의 청크 목록과 청크를 정의하는 범위가 포함됩니다.
mongos 인스턴스는 이 데이터를 캐시 하고 이를 사용하여 읽기 및 쓰기 (write) 작업을 올바른 샤드로 라우팅합니다. mongos 는 샤드 추가 와 같이 클러스터 에 대한 메타데이터 변경이 있는 경우 캐시 를 업데이트합니다. 샤드는 config 서버에서 청크 메타데이터 도 읽습니다.
config 서버는 역할 기반 액세스 제어 또는 클러스터 에 대한 내부 인증 설정과 같은 자체 관리 배포서버에 대한 인증 구성 정보도 저장 합니다.
또한 MongoDB는 config 서버를 사용하여 분산된 잠금을 관리합니다.
각 샤딩된 클러스터에는 자체 config 서버가 있어야 합니다. 서로 다른 샤딩된 클러스터에 동일한 config 서버를 사용하지 않아야 합니다.
경고
config 서버에서 관리 작업을 수행하면 샤딩된 클러스터의 성능 및 가용성에 상당한 영향을 미칠 수 있습니다. 영향을 받는 config 서버 수에 따라 cluster가 일정 기간 읽기 전용 또는 오프라인 상태일 수 있습니다.
MongoDB 8.0부터 일반적인 샤딩된 클러스터 메타데이터 외에 애플리케이션 데이터를 저장하도록 config 서버를 구성할 수 있습니다. 그러면 config 서버를 config 샤드라고 합니다. 이 페이지의 뒷부분인 Config 샤드 섹션에서 자세히 알아볼 수 있습니다.
복제본 세트 config 서버.
config 서버에 사용할 경우 복제본 세트 구성에 다음과 같은 제한이 적용됩니다.
중재자가 없어야 합니다.
지연된 멤버가 없어야 합니다.
인덱스를 작성해야 합니다(예:
members[n].buildIndexes설정이 false로 설정된 노드가 없어야 합니다).
config 서버에서 읽기 및 쓰기 작업
admin 데이터베이스 와 config 데이터베이스 가 config 서버에 존재합니다.
구성 서버에 쓰기
admin 데이터베이스에는 인증 및 권한 부여와 관련된 컬렉션과 내부 사용을 위한 다른 시스템* 컬렉션이 포함되어 있습니다.
config 데이터베이스에는 샤딩된 클러스터 메타데이터를 포함하는 컬렉션이 들어 있습니다. MongoDB는 청크 마이그레이션 또는 청크 분할 후와 같이 메타데이터가 변경되면 config 데이터베이스에 데이터를 씁니다.
사용자는 정상적인 운영 또는 유지 관리 과정에서 config 데이터베이스에 직접 쓰지 않아야 합니다.
config 서버에 쓸 때 MongoDB는 "majority"의 쓰기 고려를 사용합니다.
config 서버에서 읽기
MongoDB는 인증 및 권한 부여 데이터 및 기타 내부 사용을 위해 admin 데이터베이스에서 읽습니다.
MongoDB는 mongos 가 시작될 때 또는 청크 마이그레이션 후와 같이 메타데이터가 변경된 후 config 데이터베이스에서 읽습니다. 샤드는 config 서버에서 청크 메타데이터도 읽습니다.
복제본 세트 구성 서버에서 읽을 때 MongoDB는 "majority"의 읽기 문제 수준을 사용합니다 .
메타데이터 뷰는 최신 상태여야 합니다.
작업이 성공하려면 특정 샤드 멤버의 메타데이터 보기가 최신 상태여야 합니다. 요청 을 발행하는 샤드 와 라우터에는 동일한 버전의 청크 메타데이터 가 있어야 합니다.
메타데이터 가 최신 상태가 아닌 경우 StaleConfig 오류와 함께 작업이 실패하고 메타데이터 새로 고침 프로세스 가 트리거됩니다. 메타데이터 를 새로 고치면 운영 지연 시간 이 발생할 수 있습니다.
세컨더리 서버에서 복제 지연 이 심하면 메타데이터 새로 고침에 시간이 오래 걸릴 수 있습니다. 세컨더리 읽기의 경우 maxStalenessSeconds 을(를) 설정하다 하여 복제 지연 의 영향 을 최소화합니다.
config 서버 가용성
config 서버 복제본 세트가 프라이머리를 잃게 돼 프라이머리를 선택할 수 없게 되면 cluster의 메타데이터는 읽기 전용이 됩니다. 샤드에서의 데이터 읽기 및 쓰기는 가능하나, 복제본 세트가 프라이머리를 선택할 수 있을 때까지 청크 마이그레이션이나 청크 분할은 발생하지 않습니다.
샤딩된 클러스터에서 mongod 및 mongos 인스턴스는 샤딩된 클러스터의 복제본 세트를 모니터링합니다 (예: 샤드 복제본 세트, 구성 서버 복제본 세트).
모든 config 서버를 사용할 수 없게 되면 클러스터가 작동하지 않을 수 있습니다. 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을 모두 클러스터 내 인증에 사용할 수 있습니다.
자체 관리형 샤딩된 클러스터 배포에 대한 튜토리얼은 키파일 인증을 사용하여 클러스터 배포하기를 참조하세요.
구성 샤드
버전 8.0에 추가 되었습니다.
MongoDB 8.0 부터 다음을 수행할 수 있습니다.
일반적인 샤딩된 클러스터 메타데이터 외에도 애플리케이션 데이터를 저장하도록 config 서버를 구성합니다. 애플리케이션 데이터를 저장하는 config 서버를 config 샤드라고 합니다.
config 서버를 config 샤드 와 전용 config 서버 config 서버 간에 전환합니다.
클러스터 에는 config 서버 가 필요하지만 전용 config 서버 대신 config 샤드 가 될 수 있습니다. config 샤드 를 사용하면 필요한 노드 수가 줄어들고 배포서버 가 간소화될 수 있습니다.
애플리케이션 에 까다로운 가용성 및 복원력 요구 사항이 있는 경우 전용 config 서버 를 배포하는 것이 좋습니다. 전용 config 서버 는 중요한 클러스터 작업을 위한 격리, 전용 리소스 및 일관적인 성능을 제공합니다.
여러 개의 샤드 클러스터에 동일한 구성 샤드를 사용할 수 없습니다.
명령.
전용 config 서버 를 config 샤드 로 실행 하도록 구성하려면 transitionFromDedicatedConfigServer 명령을 실행 합니다.
전용 config 서버 로 실행 config 샤드 를 구성하려면 transitionToDedicatedConfigServer 명령을 실행 합니다.
사용자
config 샤드에서 생성된 사용자는 전용 config 서버에서 생성된 사용자와 동일한 동작을 합니다.
구성 샤드 사용 확인
To confirm that a sharded cluster uses a config shard, run the listShards command against the admin database while connected to a mongos and inspect the output for a document where _id is set to "config". If the listShards output does not contain a document where _id is set to "config", the cluster does not use a config shard.
The following example runs the listShards command and tries to find a document where _id is set to "config".
db.adminCommand({ listShards: 1 })["shards"].find(element => element._id === "config")
In this example, the returned document has _id set to "config" which confirms that this cluster uses a config shard.
{ _id: "config", host: "configRepl/localhost:27018", state: 1, topologyTime: Timestamp({ t: 1732218671, i: 13 }), replSetConfigVersion: Long('-1') }
기능 호환성 버전 다운그레이드
클러스터에 구성 샤드가 있고 기능 호환성 버전을 8.0 이전으로 다운그레이드해야 하는 경우 mongos에 연결하고 다음 절차를 수행합니다.
전용 Config 서버로 실행되도록 구성 샤드를 구성합니다.
전용 Config 서버로 실행되도록 구성 샤드를 구성하려면 transitionToDedicatedConfigServer를 실행하세요.
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
클러스터 의 모든 데이터베이스와 컬렉션을 나열합니다.
클러스터의 모든 데이터베이스를 나열하려면
listDatabases를 실행합니다.db.adminCommand( { listDatabases: 1, nameOnly: true } ) admin및config데이터베이스를 제외합니다.각 데이터베이스 에 대해 데이터베이스 의 모든 컬렉션을 나열합니다.
데이터베이스의 모든 컬렉션을 나열하려면
listCollections를 실행합니다.db.adminCommand( { listCollections: 1, nameOnly: true, filter: { type: { $ne: "view" } } } ) system으로 시작하는 컬렉션을 제외합니다.
각 비시스템 컬렉션 에 대해 컬렉션 을 새 샤드 로 이동합니다.
컬렉션을 새 샤드로 이동하려면 moveCollection을 실행하세요.
db.adminCommand( { moveCollection: "<database>.<collection>", toShard: "<new shard>", } )
밸런서가 샤딩된 컬렉션 데이터를 구성 서버에서 이동할 때까지 기다립니다.
밸런서가 샤딩된 컬렉션 데이터를 설정 서버에서 이동했는지 확인하려면 transitionToDedicatedConfigServer를 다시 실행하세요.
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
데이터 이동이 성공적으로 완료된 후의 응답에는 state:
"completed"가 포함됩니다. 응답에 state: "pendingDataCleanup"이 포함된 경우, 잠시 기다렸다가 명령 응답에 state: "completed"가 포함될 때까지 transitionToDedicatedConfigServer를 계속 호출하세요. 전체 응답 세부 사항은 removeShard를 참조하세요.
기능 호환성 버전을 설정합니다.
기능 호환성 버전을 설정하려면 setFeatureCompatibilityVersion를 실행합니다.
db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )