샤딩된 클러스터 문제 해결
이 페이지의 내용
이 페이지에서는 샤딩된 클러스터 배포 문제를 해결하기 위한 일반적인 전략을 설명합니다.
시작하기 전에
MongoDB 8.0 부터는 directShardOperations 역할 을 사용하여 샤드 에 대해 직접 명령을 실행해야 하는 유지 관리 작업을 수행할 수 있습니다.
경고
directShardOperations 역할 을 사용하여 명령을 실행하면 클러스터 가 올바르게 작동하지 않고 데이터가 손상될 수 있습니다. directShardOperations 역할 은 유지 관리 목적으로만 사용하거나 MongoDB 지원 의 지침 에 따라 사용하세요. 유지 관리 작업 수행이 완료되면 directShardOperations 역할 사용을 중지합니다.
애플리케이션 서버 또는 mongos 인스턴스를 사용할 수 없음
각 애플리케이션 서버에 자체 mongos 인스턴스가 있는 경우 다른 애플리케이션 서버는 데이터베이스에 계속 액세스할 수 있습니다. 또한 mongos 인스턴스는 영구 상태를 유지하지 않으며 상태나 데이터 손실 없이 다시 시작하여 사용할 수 없게 될 수 있습니다. mongos 인스턴스가 시작되면 구성 데이터베이스의 사본을 검색하고 쿼리 라우팅을 시작할 수 있습니다.
샤드 복제본 세트에서 단일 멤버를 사용할 수 없게 됨
복제본 세트는 샤드에 고가용성을 제공합니다. 사용할 수 없는 mongod가 프라이머리인 경우 복제본 세트가 새 프라이머리를 선출합니다. 사용할 수 없는 mongod가 세컨더리인 경우, 프라이머리와의 연결이 끊어지고 세컨더리의 모든 데이터는 계속해서 보존됩니다. 세 멤버로 이루어진 복제본 세트에서는 세트의 한 멤버가 치명적인 장애를 경험하더라도 다른 두 멤버는 데이터의 전체 사본을 가지고 있습니다. [1]
항상 가용성 중단 및 장애를 조사합니다. 시스템을 복구할 수 없는 경우 시스템을 교체하고 가능한 한 빨리 복제본 세트의 새 멤버를 생성하여 손실된 이중 환경을 교체합니다.
| [1] | 사용할 수 없는 세컨더리가 현재 oplog 항목이 남아 있는 상태에서 사용 가능해지면 일반 복제 프로세스를 사용하여 세트의 최신 상태를 따라잡을 수 있지만, 그렇지 않은 경우 초기 동기화를 수행해야 합니다. |
샤드의 모든 멤버를 사용할 수 없게 됨
샤딩된 클러스터에서 mongod 및 mongos 인스턴스는 샤딩된 클러스터의 복제본 세트를 모니터링합니다 (예: 샤드 복제본 세트, 구성 서버 복제본 세트).
복제본 세트 샤드의 모든 멤버를 사용할 수 없는 경우 해당 샤드에 보관된 모든 데이터를 사용할 수 없습니다. 그러나 다른 모든 샤드의 데이터는 계속 사용 가능하며 다른 샤드에 데이터를 읽고 쓸 수 있습니다. 그러나 애플리케이션에서 부분적인 결과를 처리할 수 있어야 하며 중단 원인을 조사하고 가능한 한 빨리 샤드 복구를 시도해야 합니다.
구성 서버 복제본 세트 멤버를 사용할 수 없게 됨
복제본 세트는 구성 서버에 고가용성을 제공합니다. 사용할 수 없는 구성 서버가 프라이머리인 경우 복제본 세트가 새 프라이머리를 선출합니다.
복제본 세트 구성 서버가 프라이머리를 잃은 후 프라이머리를 선출할 수 없는 경우 클러스터의 메타데이터는 읽기 전용이 됩니다. 샤드에서 데이터를 계속 읽고 쓸 수 있지만, 프라이머리를 사용할 수 있을 때까지 청크 마이그레이션 또는 청크 분할이 발생하지 않습니다.
참고
두 개의 데이터 센터에 복제본 세트 구성원을 분산하면 단일 데이터 센터에 비해 이점이 있습니다. 두 개의 데이터 센터로 분산된 경우,
데이터 센터 중 하나가 다운되더라도 단일 데이터 센터 배포판과 달리 데이터를 읽을 수 있습니다.
소수의 구성원이 있는 데이터 센터가 다운되더라도 복제본 세트는 읽기 작업뿐만 아니라 쓰기 작업도 계속 수행할 수 있습니다.
그러나 대다수의 구성원이 있는 데이터 센터가 다운되면 복제본 세트는 읽기 전용이 됩니다.
가능하다면 최소 3개 이상의 데이터 센터에 구성원을 배포하세요. 구성 서버 복제본 세트(CSRS)의 경우 가장 좋은 방법은 3개(또는 구성원 수에 따라 그 이상) 센터에 배포하는 것입니다. 세 번째 데이터 센터의 비용이 부담스러운 경우, 회사 정책이 허용하는 경우 데이터 보유 멤버를 두 데이터 센터에 균등하게 분산하고 나머지 멤버는 클라우드에 저장하는 것도 한 가지 방법입니다.
참고
샤딩된 클러스터를 처음 시작할 때 모든 구성 서버가 실행 중이고 사용 가능해야 합니다.
오래된 구성 데이터로 인해 커서 실패
mongos 인스턴스 중 하나 이상이 구성 데이터베이스에서 클러스터의 메타데이터 캐시를 아직 업데이트하지 않은 경우 쿼리에서 다음 경고를 반환합니다:
could not initialize cursor across all shards because : stale config detected
이 경고는 애플리케이션에 다시 전파되어서는 안 됩니다. 경고는 모든 mongos 인스턴스가 캐시를 새로 고칠 때까지 반복됩니다. 인스턴스가 캐시를 강제로 새로 고치도록 하려면 flushRouterConfig 명령을 실행합니다.
샤드 키
샤드 키 문제를 해결하려면 샤드 키 문제 해결을 참조하세요.
클러스터 가용성
클러스터 가용성을 보장하려면 다음을 따릅니다:
각 샤드는 복제본 세트여야 하며, 특정
mongod인스턴스가 실패하면 복제본 세트 멤버가 다른 샤드를 프라이머리로 선출하고 작업을 계속합니다. 하지만 전체 샤드에 접속할 수 없거나 어떤 이유로든 장애가 발생하면 해당 데이터를 사용할 수 없습니다.샤드 키는
mongos가 대부분의 작업을 단일 샤드로 격리할 수 있도록 허용해야 합니다. 단일 샤드에서 작업을 처리할 수 있는 경우 단일 샤드에 장애가 발생해도 일부 데이터만 사용할 수 없게 됩니다. 작업에서 쿼리를 위해 모든 샤드에 액세스해야 하는 경우 샤드 하나가 실패하면 전체 클러스터를 사용할 수 없게 됩니다.
Config Database String Error
config 서버는 복제본 세트로 배포해야 합니다. 샤딩된 클러스터의 mongos 인스턴스는 동일한 config 서버 복제본 세트 이름을 지정해야 하지만, 복제본 세트에 대한 다른 노드의 호스트 이름과 포트를 지정할 수 있습니다.
구성 서버에 대해 3개의 미러링된 mongod 인스턴스의 토폴로지를 사용하는 이전 버전의 MongoDB 샤딩된 클러스터를 사용하는 경우, 샤딩된 클러스터의 mongos 인스턴스는 동일한 configDB 문자열을 지정해야 합니다.
구성 서버 이동 시 다운타임 방지
CNAME을 사용하여 클러스터에 대한 config 서버를 식별하면 가동 중지 시간 없이 구성 서버의 이름을 바꾸고 번호를 다시 지정할 수 있습니다.
moveChunk commit failed 오류
청크 마이그레이션이 끝나면 샤드는 구성 데이터베이스에 연결하여 클러스터 메타데이터에서 청크의 기록을 업데이트해야 합니다. 샤드가 구성 데이터베이스에 연결하지 못하면 MongoDB는 다음 오류를 보고합니다:
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
이런 일이 발생하면 데이터 일관성을 보호하기 위해 샤드 복제본 세트의 프라이머리 멤버가 종료됩니다. 세컨더리 멤버가 구성 데이터베이스에 액세스할 수 있는 경우, 투표 후 샤드의 데이터에 다시 액세스할 수 있게 됩니다.
사용자는 청크 마이그레이션 실패를 독립적으로 해결해야 합니다. 이 문제가 발생할 경우 MongoDB Community 또는 MongoDB 지원팀에 문의해 문제를 해결하도록 하세요.
일관성 없는 샤딩 메타데이터
MongoDB 7.0부터는 checkMetadataConsistency 명령을 사용하여 이전 버전의 MongoDB에서 발생한 버그로 인해 샤딩 메타데이터에 불일치 및 손상이 있는지 확인할 수 있습니다.
샤딩 메타데이터의 불일치는 다음과 같은 경우에 발생할 수 있습니다.
MongoDB 5.0 이전 릴리스에서 업그레이드된 클러스터로, 과거 DDL 작업으로 인해 데이터가 손상되었을 수 있습니다.
업그레이드 또는 다운그레이드 절차와 같은 유지 관리 작업입니다.
이러한 불일치로 인해 잘못된 쿼리 결과 또는 데이터 손실이 발생할 수 있습니다.
샤딩 메타데이터에 불일치가 있는지 확인하려면 checkMetadataConsistency 명령을 실행합니다.
db.runCommand( { checkMetadataConsistency: 1 } )
{ cursor: { id: Long("0"), ns: "test.$cmd.aggregate", firstBatch: [ { type: "MisplacedCollection", description: "Unsharded collection found on shard different from database primary shard", details: { namespace: "test.authors", shard: "shard02", localUUID: new UUID("1ad56770-61e2-48e9-83c6-8ecefe73cfc4") } } ], }, ok: 1 }
checkMetadataConsistency 명령이 반환한 문서는 클러스터의 샤딩 메타데이터에서 MongoDB가 식별한 불일치를 나타냅니다.
checkMetadataConsistency 명령이 반환하는 불일치 문서에 대한 자세한 내용은 불일치 유형을 참조하세요.