mongo (3.2) : 파일 시스템에서 여전히 fsyncLock() 파일을 수정하여 백업

Question

tar를 사용하여 mongo 파일 시스템을 백업 할 때, 복제 세트의 보조 파일을 사용할 때 tar는 tar 프로세스 중에 파일이 변경되었다고 말합니다. lock 명령이 실행되었지만. 안정적인 백업을 위해서는 이러한 일이 발생하지 않아야합니다. 내가 누락 된 것?

devtest:SECONDARY> use admin 
switched to db admin 
devtest:SECONDARY> db.fsyncLock() 
{ 
     "info" : "now locked against writes, use db.fsyncUnlock() to unlock", 
     "seeAlso" : "http://dochub.mongodb.org/core/fsynccommand", 
     "ok" : 1 
} 

타르 과정을 확인한다이 실행되는 동안 변경된 파일을 찾는 find 명령을 사용하여. diff를 사용하여 이러한 파일의 이전 버전과 이후 버전을 비교해도 확인합니다. 항상이 파일 들인 것처럼 보입니다.

/var/lib/mongo # find -cmin 1 
. 
./WiredTiger.turtle 
./WiredTiger.wt 
./diagnostic.data 
./diagnostic.data/metrics.interim 

Mongo 3.2 및 wiredtiger가 사용됩니다.

/etc/mongo.conf 
storage: 
    directoryPerDB: true 
    dbPath: /var/lib/mongo 
    engine: "wiredTiger" 
    wiredTiger: 
    engineConfig: 
     directoryForIndexes: true 
    collectionConfig: 
     blockCompressor: snappy 
    journal: 
    enabled: true 

문서는 파일이 변경되지 않는다고합니다. 아마 전용 "데이터"파일

https://docs.mongodb.com/v3.2/reference/method/db.fsyncLock/

버전 3.2에서 변경 ... 변경되지 않습니다 : db.fsyncLock() 데이터 파일이 MMAPv1 또는를 사용하여 MongoDB의 인스턴스에 대한 변경하지 않는 것이 보장 할 수 있습니다 따라서 WiredTiger 스토리지 엔진을 사용하여 백업을 생성하기위한 일관성을 제공합니다.

이전 MongoDB 버전에서 db.fsyncLock()은 WiredTiger에 대한 저수준 백업 (예 : 파일 복사 cp, scp, tar)을위한 일관된 파일 집합을 보장 할 수 없습니다.

Answer 1

나는 mongodb이 실행 중일 때 데이터를 계속 저장해야한다고 추측하지만, 수집 데이터를 변경하지 않으므로 데이터를 백업하는 것이 안전하다고 판단됩니다.

확실하지 않으면 항상 db.shutdownServer() 일 수 있습니다. 그러면 디스크를 강제로 플러시하고 서비스를 중지 한 다음 다시 백업 한 다음 mongod 프로세스를 다시 시작하십시오.