문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

복제 세트 페일오버 중 롤백

이 페이지의 내용

  • 롤백 데이터 수집
  • 복제 세트 롤백 방지
  • 롤백 고려 사항

롤백은 장애 조치 후 구성원이 복제본 세트에 다시 참여할 때 이전 기본 구성원에 대한 쓰기 작업을 되돌립니다. 롤백은 프라이머리가 물러나기 전에 세컨더리가 성공적으로 복제하지 못한 쓰기 작업을 프라이머리가 수락한 경우에만 필요합니다. 기본이 보조로 세트에 다시 합류하면 쓰기 작업을 되돌리거나 "롤백"하여 다른 구성원과의 데이터베이스 일관성을 유지합니다.

MongoDB는 롤백을 피하려고 시도하는데, 이는 드문 경우입니다. 롤백이 발생하는 경우 네트워크 파티션으로 인해 발생하는 경우가 많습니다. 이전 기본의 작업 처리량을 따라잡을 수 없는 보조는 롤백의 크기와 영향을 증가시킵니다.

쓰기 작업이 기본 구성원이 내려가기 전에 복제본 세트의 다른 구성원으로 복제되고 해당 구성원이 복제본 세트의 대부분에서 계속 사용 가능하고 액세스할 수 있는 경우 롤백이 발생하지 않습니다.

createRollbackDataFiles 매개 변수는 롤백 중에 롤백 파일을 생성할지 여부를 제어합니다.

기본적으로 롤백이 발생하면 MongoDB는 롤백 데이터를 BSON 파일에 씁니다.

데이터가 롤백되는 각 컬렉션에 대해 롤백 파일은 <dbpath>/rollback/<collectionUUID> 디렉토리에 있으며 파일 이름은 다음과 같습니다.

removed.<timestamp>.bson

예를 들어 reporting 데이터베이스의 컬렉션 comments에 대한 데이터가 롤백된 경우:

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

여기서 <dbpath>mongoddbPath입니다.

컬렉션 이름

컬렉션 이름을 얻으려면 MongoDB 로그에서 rollback file을 검색하면 됩니다. 예를 들어, 로그 파일이 /var/log/mongodb/mongod.log인 경우 grep를 사용하여 로그에서 "rollback file"의 인스턴스를 검색할 수 있습니다.

grep "rollback file" /var/log/mongodb/mongod.log

또는 모든 데이터베이스를 반복하여 일치하는 항목이 나올 때까지 특정 UUID에 대해 db.getCollectionInfos()를 실행할 수 있습니다. 예를 들면 다음과 같습니다.

var mydatabases=db.adminCommand("listDatabases").databases;
var foundcollection=false;
for (var i = 0; i < mydatabases.length; i++) {
let mdb = db.getSiblingDB(mydatabases[i].name);
collections = mdb.getCollectionInfos( { "info.uuid": UUID("20f74796-d5ea-42f5-8c95-f79b39bad190") } );
for (var j = 0; j < collections.length; j++) { // Array of 1 element
foundcollection=true;
print(mydatabases[i].name + '.' + collections[j].name);
break;
}
if (foundcollection) { break; }
}

롤백 작업이 컬렉션 드롭 또는 문서 삭제인 경우 컬렉션 드롭 또는 문서 삭제의 롤백은 롤백 데이터 디렉터리에 기록되지 않습니다.

경고

쓰기 작업에서 { w: 1 } 쓰기 고려 (write concern)를 사용하는 경우 쓰기 작업이 완료되기 전에 프라이머리가 다시 시작되면 롤백 디렉토리는 oplog hole 이후에 제출된 쓰기를 제외할 수 있습니다.

롤백 파일의 내용을 읽으려면 bsondump 를 사용합니다. 관리자는 애플리케이션의 콘텐츠와 지식을 기반으로 다음 조치를 결정할 수 있습니다.

복제본 세트의 경우 쓰기 고려 { w: 1 }은 프라이머리에서의 쓰기 작업 승인만 제공합니다. 쓰기 작업이 세컨더리에 복제되기 전에 프라이머리가 강등되었을 경우 데이터가 롤백될 수 있습니다. 여기에는 { w: 1 } 쓰기 고려를 사용하여 커밋하는 다중 문서 트랜잭션에 쓰여진 데이터가 포함됩니다.

클라이언트에 승인된 데이터의 롤백을 방지하려면 저널링을 활성화한 상태에서 모든 투표 노드를 실행하고 { w: "majority" } 쓰기 고려를 사용하여 쓰기 작업이 실행하는 클라이언트에 승인과 함께 반환되기 전에 복제본 세트 노드의 과반수로 전파되도록 합니다.

MongoDB 5.0부터 { w: "majority" } 는 대부분의 MongoDB 배포에 대한 기본 쓰기 문제입니다. Implicit Default Write Concern을 참조하십시오.

writeConcernMajorityJournalDefaultfalse로 설정하면 MongoDB는 w: "majority" 쓰기가 디스크 저널에 작성되는 것을 기다리지 않고 쓰기를 확인합니다. 따라서 주어진 복제본 세트의 노드 과반수 이상이 일시적으로 손실된 경우(충돌, 재시작 등), "majority" 쓰기 작업이 롤백될 가능성이 있습니다.

다중 문서 트랜잭션 트랜잭션이 커밋되면 트랜잭션에서 이루어진 모든 데이터 변경 사항이 저장되고 트랜잭션 외부에서 볼 수 있습니다. 즉, 트랜잭션은 다른 트랜잭션을 롤백하는 동안 일부 변경 사항을 커밋하지 않습니다.

트랜잭션이 커밋될 때까지 트랜잭션에서 변경된 데이터는 트랜잭션 외부에 표시되지 않습니다.

그러나 트랜잭션이 여러 샤드에 쓰기를 수행하는 경우, 모든 외부 읽기 작업이 커밋된 트랜잭션의 결과가 샤드 전체에 표시될 때까지 기다릴 필요는 없습니다. 예를 들어, 트랜잭션이 커밋되고 쓰기 1이 샤드 A에 표시되지만 쓰기 2가 샤드 B에 아직 표시되지 않는 경우, 읽기 고려 "local"의 외부 읽기는 쓰기 2를 보지 않고 쓰기 1의 결과를 읽을 수 있습니다.

버전 4.2부터 MongoDB는 멤버가 ROLLBACK 상태에 들어가면 진행 중인 모든 사용자 작업을 종료합니다.

인덱스 빌드 프로세스에 대한 자세한 내용은 채워진 컬렉션의 인덱스 빌드를참조하세요.

"majority" 읽기 고려를 비활성화하면 인덱스를 수정하는 collMod 명령이 롤백 되지 않습니다. 이러한 작업을 롤백해야 하는 경우 영향을 받는 노드를 프라이머리 노드와 다시 동기화해야 합니다.

MongoDB는 크기 제한이 다른 다음 롤백 알고리즘을 지원합니다.

  • 타임스탬프로 복구하면 이전 프라이머리가 일관된 시점으로 되돌아가 동기화 소스의 기록된 분기를 따라잡을 때까지 작업을 적용합니다. 이것이 기본 롤백 알고리즘입니다.

    이 알고리즘을 사용할 때 MongoDB는 롤백할 수 있는 데이터의 양을 제한하지 않습니다.

  • 다시 가져오기를 통한 롤백은 이전 프라이머리가 자신의 oplog와 동기화 소스의 oplog 사이의 공통점을 찾습니다. 그런 다음 노드는 이 공통점에 도달할 때까지 해당 oplog의 모든 작업을 검사하고 되돌립니다. 다시 가져오기를 통한 롤백은 구성 파일의 enableMajorityReadConcern 설정이 false로 설정된 경우에만 발생합니다.

    이 알고리즘을 사용할 때 MongoDB는 최대 300MB의 데이터만 롤백할 수 있습니다.

    참고

    MongoDB 5.0부터 enableMajorityReadConcerntrue로 설정되며 변경할 수 없습니다.

롤백 시간 제한은 기본값이 24시간이며 rollbackTimeLimitSecs 매개변수를 사용하여 구성할 수 있습니다.

MongoDB는 경과된 시간을 oplog의 첫 번째 공통 작업부터 롤백되는 멤버의 oplog의 마지막 항목까지의 시간으로 측정합니다.

← 복제본 세트 선거