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

포 그라운드(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의 메모리 사용량에 대한 기본 제한은 200MB이며 단일 createIndexes 명령을 사용하여 빌드된 모든 인덱스 간에 공유됩니다. 메모리 제한에 도달하면 createIndexes는 --dbpath 디렉토리 내의 _tmp 라는 하위 디렉토리에 있는 임시 디스크 파일을 사용하여 빌드를 완료합니다.

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

호스트 컴퓨터의 사용 가능한 여유 RAM이 제한적일 경우, 시스템 RAM을 늘리기 위해 유지 관리 시간을 예약할 필요가 있을 수 있습니다. 이는 mongod의 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 서버 프라이머리는 주기적으로 샤딩된 컬렉션의 샤드 간 인덱스 불일치가 있는지 확인합니다. 이러한 주기적 검사를 구성하려면 enableShardedIndexConsistencyCheck 및 shardedIndexConsistencyCheckIntervalMS를 참조하세요.

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

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

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

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

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