컬렉션 리샤딩

이 작업에 대하여

• 한 번에 하나의 컬렉션만 리샤딩할 수 있습니다.

• writeConcernMajorityJournalDefault은(는) true이어야 합니다.

• 고유성 제약 조건이 있는 컬렉션을 리샤드하려면 새 샤드 키가 기존의 모든 고유 인덱스에 대한 고유 인덱스 요구 사항을 충족해야 합니다.

• 리샤딩 작업이 진행 중인 동안 리샤딩되는 컬렉션에서는 다음 명령 및 해당 셸 메서드가 지원되지 않습니다.

  • collMod

  • convertToCapped

  • createIndexes

  • createIndex()

  • drop

  • drop()

  • dropIndexes

  • dropIndex()

  • renameCollection

  • renameCollection()

• 다음 작업 중 하나를 실행 하면 작업이 실행되기 전에 리샤딩이 완료될 때까지 대기합니다.

  • addShard

  • removeShard

  • dropDatabase 리샤딩 중인 컬렉션 호스팅하는 데이터베이스 에서

• 리샤딩하려는 컬렉션이 MongoDB Search를 사용하는 경우, 리샤딩 작업이 완료되면 검색 인덱스 사용할 수 없게 됩니다. 리샤딩 작업이 완료되면 검색 인덱스 수동으로 다시 작성해야 합니다.

• 리샤딩하려는 컬렉션 Atlas Online Archives에 보관되는 경우, 리샤딩 작업이 완료되면 온라인 아카이브 파일이 Orphaned로 표시됩니다. Active 상태 의 동일한 조합에 대한 다른 아카이브가 없는 한 고아 아카이브와 동일한 데이터베이스, 컬렉션 및 필드에 대해 다른 온라인 아카이브를 생성할 수 있습니다.

시작하기 전에

컬렉션 리샤딩을 시작하기 전에 다음 요구 사항을 충족하는지 확인하세요.

• 애플리케이션 은 영향을 받는 컬렉션 이 쓰기를 차단하는 2초의 기간을 허용할 수 있습니다. 쓰기가 차단되는 기간 동안 애플리케이션 의 지연 시간 이 증가합니다.

  워크로드가 이러한 요구 사항을 수용할 수 없는 경우에는 대신 샤드 키를 개선하는 것이 좋습니다.

• 데이터베이스는 다음과 같은 리소스 요구 사항을 충족합니다.

  • 각 수신자 샤드 의 사용 가능한 저장 공간이 리샤딩하려는 컬렉션 의 저장 크기에 총 인덱스 크기를 더한 값을 샤드 수로 나눈 값의 두 배 이상이어야 합니다.

    ( ( collection_storage_size + index_size ) * 2 ) / shard_count = storage_req

    예시 를 들어, 저장 크기가 2 TB 데이터이고 인덱스 400 GB 인 컬렉션 생각해 보겠습니다. 4개의 샤드에 분산하려면 다음이 필요합니다.

    ( ( 2 TB collection + 0.4 TB index ) * 2 ) / 4 shards = 1.2 TB storage

    이 컬렉션 리샤딩하려면 각 샤드 1.2 이(가) 필요합니다. TB의 사용 가능한 저장.

    MongoDB Atlas 에서 리샤딩 작업을 위해 다음 저장 계층 으로 업그레이드 해야 할 수도 있습니다. 작업이 완료되면 다운그레이드할 수 있습니다.

  • I/O 용량 이 50% 미만인지 확인합니다.

  • CPU 로드가 80% 미만인지 확인합니다.

  중요

  이러한 요구 사항은 데이터베이스에 의해 적용되지 않습니다. 충분한 리소스를 할당하지 못하면 다음과 같은 결과가 발생할 수 있습니다.

  • 데이터베이스 공간이 부족하여 종료되는 경우

  • 성능 저하

  • 작업이 예상보다 오래 걸리는 경우

  애플리케이션 에 트래픽이 적은 기간이 있는 경우 가능하면 해당 기간 동안 컬렉션 에 대해 이 작업을 수행합니다.

• 리샤딩하기 전에 새 샤드 키 에 인덱스 생성할 필요가 없습니다. 리샤딩 작업은 인덱스 단계에서 필요한 인덱스를 자동으로 빌드합니다.

• 진행 중인 인덱스 빌드가 없습니다. 실행 인덱스 빌드를 확인하려면 $currentOp을 사용합니다.

  db.getSiblingDB("admin").aggregate( [
     { $currentOp : { idleConnections: true } },
     { $match: {
           $or: [
               { "op": "command", "command.createIndexes": { $exists: true } },
               { "op": "none", "msg": /^Index Build/ }
           ]
        }
     }
  ] )

  결과 문서에서 inprog 필드 값이 빈 배열이면 진행 중인 인덱스 빌드는 없습니다.

  {
     inprog: [],
     ok: 1,
     '$clusterTime': { ... },
     operationTime: <timestamp>
  }

단계

컬렉션 리샤딩 작업에서 샤드는 다음과 같을 수 있습니다.

• 기증자는 현재 샤딩된 컬렉션의 청크를 저장합니다.

• 수신자는 샤드 키와 구역을 기반으로 샤드 컬렉션의 새 청크를 저장합니다.

샤드는 기증자와 수신자가 동시에 될 수 있습니다.

config 서버 프라이머리는 항상 리샤딩 코디네이터이며 리샤딩 작업의 각 단계를 시작합니다.

db.adminCommand({
  reshardCollection: "<database>.<collection>",
  key: <shardkey>
})

db.adminCommand({
  reshardCollection: "<database>.<collection>",
  key: <shardkey>,
  forceRedistribution: true
})

db.getSiblingDB("admin").aggregate([
  { $currentOp: { allUsers: true, localOps: false } },
  {
    $match: {
      type: "op",
      "originatingCommand.reshardCollection": "<database>.<collection>"
    }
  }
])

[
  {
    shard: '<shard>',
    type: 'op',
    desc: 'ReshardingRecipientService | ReshardingDonorService | ReshardingCoordinatorService <reshardingUUID>',
    op: 'command',
    ns: '<database>.<collection>',
    originatingCommand: {
      reshardCollection: '<database>.<collection>',
      key: <shardkey>,
      unique: <boolean>,
      collation: { locale: 'simple' }
    },
    totalOperationTimeElapsedSecs: <number>,
    remainingOperationTimeEstimatedSecs: <number>,
    ...
  },
  ...
]

행동

오류 사례