예기치 않은 종료 후 자체 관리 독립형 복구하기
경고
다음 절차는 독립 실행형 mongod 인스턴스 버전 6.0에 적용됩니다. 다른 MongoDB 버전의 경우 해당 버전의 매뉴얼을 참조하세요.
이 튜토리얼을 사용하여 복제본 세트 멤버를 복구할 수 없습니다. 대신 백업에서 복원하거나 자체 관리 복제본 세트의 멤버 재동기화하기에서 설명한 대로 세트의 다른 멤버로부터 재동기화해야 합니다.
팁
저널링을 활성화하여 실행하는 경우, 서버가 저널 파일을 사용하여 데이터 파일을 자동으로 깨끗한 상태로 복원할 수 있으므로 복구를 실행할 필요가 거의 없습니다. 그러나 디스크 수준 데이터 손상을 복구해야 하는 경우 복구를 실행해야 할 수도 있습니다.
디스크 수준의 데이터 손상 또는 데이터 파일 누락으로 인해 mongod 인스턴스가 시작되지 않을 수 있으며 저널 파일이 충분하지 않아 자동으로 복구되지 않을 수 있습니다.
2018-10-24T18:05:18.248-04:00 W STORAGE [initandlisten] Detected unclean shutdown - mongod.lock is not empty. ... 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] Failed to get the cursor for uri: table:collection-2-6854866147293273505 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] This may be due to missing data files. ... ... ***aborting after fassert() failure
이러한 경우 dbPath에 비어 있지 않은 mongod.lock 파일이 포함됩니다.
다음 절차는 mongod --repair를 사용하여 이러한 사례에서 복구를 진행합니다.
경고
다른 옵션이 없는 경우에만 mongod --repair를 사용하세요. 이 연산은 복구 프로세스 중에 손상된 데이터를 제거하고 저장하지 않습니다.
WiredTiger 스토리지 엔진의 경우 mongod --repair는 다음을 수행합니다.
일관되지 않은 인덱스가 포함된 컬렉션의 모든 인덱스를 다시 작성합니다.
손상된 데이터를 삭제합니다.
누락된 데이터/메타데이터 파일에 대한 빈/스텁 파일을 생성합니다.
절차
중요
mongod 프로세스를 정상적으로 실행하는 것과 동일한 사용자로 복구 작업을 실행하여 MongoDB 데이터 파일의 권한 변경을 방지합니다.
데이터 파일의 백업을 생성합니다.
--dbpath에 있는 데이터 파일의 백업 복사본을 생성합니다.
참고
어떤 이유로든 복구가 완료되지 않으면 --repair 옵션을 사용하여 인스턴스를 다시 시작해야 복구를 완료할 수 있습니다.
| [1] | 일반적으로 mongod.lock 파일을 수동으로 제거하지 않아야 합니다. 대신 위의 절차를 사용하여 데이터베이스를 복구합니다. 심각한 상황에서는 파일을 제거하고, 손상 가능성이 있는 파일을 사용하여 데이터베이스를 시작하고, 데이터베이스에서 데이터 복구를 시도할 수 있습니다. 그러나 이러한 상황에서 데이터베이스의 상태를 예측하는 것은 불가능합니다. |