채워진 컬렉션을 기반으로 하는 인덱스 빌드

포 그라운드(Foreground) 및 백그라운드 빌드와의 비교

이전 버전의 MongoDB는 전경 또는 배경에서 인덱스 빌드를 지원했습니다. 전경 인덱스 빌드는 속도가 빠르고 더 효율적인 인덱스 데이터 구조를 생성하지만, 빌드 기간 동안 컬렉션의 상위 데이터베이스에 대한 모든 읽기-쓰기 액세스를 차단해야 했습니다. 전경 인덱스 빌드는 속도가 느리고 결과 효율성이 낮았지만 빌드 프로세스 중에 데이터베이스 및 해당 컬렉션에 대한 읽기-쓰기 액세스를 허용했습니다.

이제 인덱스 빌드는 메타데이터 변경 사항을 보호하기 위해 빌드 프로세스의 시작과 끝에 인덱싱되는 컬렉션에 대해서만 배타 락을 얻습니다. 빌드 프로세스의 나머지 부분에서는 백그라운드 인덱스 빌드의 양보 동작을 사용하여 빌드 중 컬렉션에 대한 읽기-쓰기 액세스를 최대화합니다. 인덱스 빌드는 더 관대한 잠금 동작에도 불구하고 여전히 효율적인 인덱스 데이터 구조를 생성합니다.

최적화된 인덱스 빌드 성능은 최소한 배경 인덱스 빌드와 동등합니다. 빌드 프로세스 중에 업데이트를 거의 또는 전혀 수신하지 않는 워크로드의 경우, 최적화된 인덱스 빌드는 동일한 데이터에 대한 전경 인덱스 빌드만큼 빠를 수 있습니다.

db.currentOp() 를 사용하여 진행 중인 인덱스 빌드의 진행 상황을 모니터링합니다.

MongoDB는 createIndexes 또는 해당 셸 헬퍼인 createIndex() 및 createIndexes()에 지정된 background 인덱스 빌드 옵션을 무시합니다.

인덱스 빌드 중 제약 조건 위반

고유 인덱스와 같이 컬렉션에 제약 조건을 적용하는 인덱스의 경우 mongod 는 인덱스 빌드가 완료된 후 모든 기존 문서와 동시에 작성된 문서에서 해당 제약 조건을 위반하는지 확인합니다. 인덱스 제약 조건을 위반하는 문서가 인덱스 빌드 중에 존재할 수 있습니다. 빌드가 끝날 때 인덱스 제약 조건을 위반하는 문서가 있으면 mongod 가 빌드를 종료하고 오류를 발생시킵니다.

예를 들어 채워진 컬렉션 inventory 을 생각해 보겠습니다. 관리자가 product_sku 필드에 고유 인덱스를 생성하려고 합니다. 컬렉션의 문서에 product_sku 에 대해 중복된 값이 있는 경우 인덱스 빌드를 성공적으로 시작할 수 있습니다. 빌드가 끝날 때까지 위반 사항이 여전히 존재하면 mongod 가 빌드를 종료하고 오류를 발생시킵니다.

마찬가지로 인덱스 빌드가 진행되는 동안 애플리케이션이 product_sku 값을 중복하여 inventory 컬렉션에 문서를 성공적으로 작성할 수 있습니다. 빌드가 끝날 때까지 위반 사항이 여전히 존재하면 mongod 가 빌드를 종료하고 오류를 발생시킵니다.

제약 조건 위반으로 인한 인덱스 빌드 실패 위험을 줄이기 위해서는 다음 조치를 취해야 합니다:

• 컬렉션 내의 문서들이 인덱스 제약 조건을 위반하지 않는지 확인합니다.

• 위반 없는 쓰기 작업을 보장할 수 없는 애플리케이션의 컬렉션에 대한 모든 쓰기를 중.

최대 동시 인덱스 빌드.

기본적으로 서버는 최대 3개의 동시 인덱스 빌드를 허용합니다. 허용되는 동시 인덱스 빌드 수를 변경하려면 maxNumActiveUserIndexBuilds 매개 변수를 수정합니다.

동시에 진행되는 인덱스 빌드의 수가 maxNumActiveUserIndexBuilds에 의해 지정된 한도에 도달하면, 서버는 추가 인덱스 빌드를 차단하고 동시 인덱스 빌드의 수가 한도 아래로 떨어질 때까지 기다립니다.

쓰기 작업량이 많은 워크로드 중 인덱스 빌드

대상 컬렉션에 쓰기 부하가 많은 기간에 인덱스를 빌드하면 쓰기 성능이 저하되고 인덱스 빌드 시간이 길어질 수 있습니다.

애플리케이션이 컬렉션에 대한 쓰기 작업을 중지하거나 줄이는 유지 관리 기간을 지정하는 것이 좋습니다. 빌드 프로세스의 잠재적인 부정적인 영향을 완화하려면 이 유지 관리 기간 동안 인덱스 빌드를 시작하세요.

사용 가능한 시스템 메모리(RAM) 부족

createIndexes 는 컬렉션에 하나 이상의 인덱스 작성을 지원합니다. createIndexes 는 디스크의 메모리와 임시 파일의 조합을 사용하여 인덱스 빌드를 완료합니다. createIndexes 의 메모리 사용량에 대한 기본 제한은 200 메가바이트이며, 단일 createIndexes 명령을 사용하여 구축된 모든 인덱스 간에 공유됩니다. 메모리 제한에 도달하면 createIndexes 는 --dbpath 디렉토리 내의 _tmp 이라는 하위 디렉토리에 있는 임시 디스크 파일을 사용하여 빌드를 완료합니다.

maxIndexBuildMemoryUsageMegabytes 서버 매개변수를 설정하여 메모리 제한을 덮어쓸 수 있습니다. 메모리 제한을 높게 설정하면 인덱스 빌드가 더 빨리 완료될 수 있습니다. 하지만 이 제한을 시스템의 미사용 RAM에 비해 너무 높게 설정하면 메모리가 고갈되고 서버가 종료될 수 있습니다.

호스트 시스템의 사용 가능한 RAM이 제한되어 있는 경우 mongod RAM 사용량을 수정하기 전에 유지 관리 기간을 예약하여 총 시스템 RAM을 늘려야 할 수 있습니다.

쓰기 우려와 대조되는 쿼럼 커밋

쿼럼 커밋과 쓰기 고려 간에는 중요한 차이점이 있습니다.

• 인덱스 빌드는 쿼럼 커밋 사용합니다.

• 쓰기 작업은 쓰기 고려 사용합니다.

클러스터 내의 각 데이터 보유 노드는 투표권을 가진 노드입니다.

쿼럼 커밋은 동시 인덱스 빌드 를 커밋하기 위해 준비해야 하는 데이터 보유 투표 멤버의 수 또는 프라이머리를 포함한 투표 멤버를 지정합니다. 프라이머리가 커밋을 실행하기 전에

쓰기 고려는 쓰기 작업이 지정된 수의 인스턴스로 전파되었다는 확인 수준입니다.

커밋 쿼럼 프라이머리는 프라이머리가 인덱스 빌드를 커밋하기 전에 인덱스 빌드를 완료할 준비가 되어 있어야 하는 노드 수를 지정합니다. 반대로 프라이머리에서 인덱스 빌드를 커밋한 경우 쓰기 고려가 명령이 반환되기 전에 인덱스 빌드를 완료해야 하는 노드 수를 지정합니다.

프라이머리 인덱스에서 중단된 인덱스 빌드 mongod

MongoDB 5 부터 시작.0, 프라이머리 mongod 가 "force" : true 로 깨끗한 shutdown 를 수행하거나 인덱스 빌드 중에 SIGTERM 신호를 수신하고 commitQuorum 이 기본값 votingMembers 로 설정되어 있는 경우 인덱스 빌드 진행 상황이 저장됩니다. 디스크에. mongod 는 다시 시작될 때 인덱스 빌드를 자동으로 복구하고 저장된 체크포인트부터 계속 진행합니다. 이전 버전에서는 인덱스 빌드가 중단되면 처음부터 다시 시작해야 했습니다.

세컨더리 인덱스에서 중단된 인덱스 빌드 mongod

MongoDB 5 부터 시작.0, 세컨더리 mongod 가 "force" : true 로 깨끗한 shutdown 를 수행하거나 인덱스 빌드 중에 SIGTERM 신호를 수신하고 commitQuorum 이 기본값 votingMembers 로 설정되어 있는 경우 인덱스 빌드 진행률이 저장됩니다. 디스크에. mongod 는 다시 시작될 때 인덱스 빌드를 자동으로 복구하고 저장된 체크포인트부터 계속 진행합니다. 이전 버전에서는 인덱스 빌드가 중단되면 처음부터 다시 시작해야 했습니다.

mongod 는 복구 중인 인덱스가 빌드되는 동안 시작 프로세스를 수행할 수 있습니다.

mongod 를 독립형으로 다시 시작하는 경우(예: replication.replSetName 제거 또는 주석 처리 또는 --replSetName 생략) mongod 에서 인덱스 빌드를 다시 시작할 수 없습니다. 빌드는 수동으로 dropped 될 때까지 일시 중지된 상태로 유지됩니다.

독립 실행형에서 중단된 인덱스 빌드 mongod

인덱스 빌드 중에 mongod 가 종료되면 인덱스 빌드 작업과 모든 진행 상황이 손실됩니다. mongod 을(를) 다시 시작해도 인덱스 빌드는 다시 시작되지 않습니다. 인덱스 빌드를 다시 시작하려면 createIndex() 작업을 다시 실행해야 합니다.

빌드 프로세스 중 롤백

MongoDB 5 부터 시작.0 인덱스 빌드 중에 노드가 이전 상태로 롤백되면 인덱스 빌드 진행 상황이 디스크에 저장됩니다. 롤백이 완료될 때 아직 수행해야 할 작업이 남아 있는 경우 mongod 는 인덱스 빌드를 자동으로 복구하고 저장된 체크포인트부터 계속 진행합니다.

MongoDB는 진행 중인 인덱스 빌드를 일시 중지하여 롤백을 수행할 수 있습니다.

• 롤백이 인덱스 빌드를 되돌리지 않으면 MongoDB는 롤백을 완료한 후 인덱스 빌드를 다시 시작합니다.

• 롤백으로 인덱스 빌드가 되돌려진 경우에는 롤백 완료 후 인덱스를 다시 생성해야 합니다.

샤드 컬렉션의 인덱스 일관성 검사

샤드된 컬렉션이 일관성 없는 인덱스를 가지게 되는 경우는 컬렉션에 대한 청크를 포함하는 각 샤드에 정확히 동일한 인덱스(인덱스 옵션 포함)가 없을 때입니다. 일반 작업 중에는 일관성 없는 인덱스가 발생하지 않아야 하지만,

• 예를 들어 사용자가 unique 키 제약 조건을 사용하여 인덱스를 생성 중이고 하나의 샤드에 중복 문서가 있는 청크가 포함되어 있는 경우와 같이 일관성 없는 인덱스가 발생할 수 있습니다. 이러한 경우 인덱스 생성 작업은 중복이 없는 샤드에서는 성공할 수 있지만 중복이 있는 샤드에서는 실패할 수 있습니다.

• 사용자가 샤드 전체에 걸쳐 인덱스를 롤링 방식(즉, 샤드 전체에 걸쳐 하나씩 수동으로 인덱스를 생성)으로 생성하는 경우, 연결된 샤드에 대한 인덱스를 생성하지 못하거나 다른 사양으로 인덱스를 잘못 생성하는 경우입니다.

config 서버 프라이머리는 주기적으로 샤드 collection에 대해 샤드 간 인덱스 불일치를 확인합니다. 이러한 주기적 검사를 구성하려면 enableShardedIndexConsistencyCheck 및 shardedIndexConsistencyCheckIntervalMS 을(를) 참조하세요.

serverStatus 명령은 config 서버 프라이머리에서 실행될 때 인덱스 불일치를 보고하기 위해 shardedIndexConsistency 필드를 반환합니다.

샤드 컬렉션에 인덱스가 일관되지 않은지 확인하려면 샤드에서 일관되지 않은 인덱스 찾기를 참조하세요.

로그에서 중지된 인덱스 빌드와 다시 시작된 인덱스 빌드 관찰

인덱스가 작성되는 동안 진행률이 MongoDB 로그에 기록됩니다. 인덱스 빌드가 중지되었다가 재개되면 다음과 같은 필드가 포함된 로그 메시지가 표시됩니다.

 "msg":"Index build: wrote resumable state to disk",
 "msg":"Found index from unfinished build",