답변:
dbpath보조가 복구 중 상태가 된 이유를 알 수 없으므로 약간 안전하지 않습니다.
위와 같지만 프로세스 중에 응용 프로그램을 중지하십시오. 이렇게하면 응용 프로그램이 보조에서 복제 할 수있는 것보다 많은 데이터를 삽입 할 가능성이 없습니다. 그러나 생산 중에 문제가 발생할 수 있습니다.
dbpath을 모두 제거 보조dbpath를 두 보조 모두에 복사하십시오.dbpath몇 가지 참고 사항 :
MMS를 사용하십시오 . 무료이며 쉽게 설정할 수 있으며 복제 세트에 대한 유용한 정보를 제공합니다. "복제 지연"값을 0으로 유지하고 복제 지연이 "복제 oplog 창"보다 크지 않도록 필요한 모든 수단을 취하십시오.
항상 1Gb 네트워크와 (미안한) RAM이 있는지 확인하십시오. 많을수록 좋습니다. 추가적인 경험 법칙 : RAM을 두 배로 늘리고 SSD를 사용하지 않는 것 (RAM이 합당한 한도 내에서 남아 있음)보다 RAM과 SSD의 절반을 차지합니다.
면책 조항 : 프로덕션 데이터를 다루기 전에 항상 백업하십시오.
보조의 새 dbpath에서 스크래치를 시작하더라도 복제 프로세스가 실패하므로 oplog에서 일부를 변경해야 합니다. oplog의 크기는 모든 응용 프로그램 쓰기를 처리 할 수 있도록 최적의 값으로 설정해야합니다.
oplog 크기 늘리기 :
기본 서버 종료
use admin
db.shutdownServer()기본으로 독립형으로 시작하고 다른 포트에서 실행 37017
포트 37017에서 몽고에 로그인
mongo --port 37017로컬 데이터베이스에서 이전 내용 제거
안전을 위해 떨어 뜨리기 전에 오래된 oplog를 백업하십시오.
mongodump --db local --collection 'oplog.rs' --port 37017로컬 데이터베이스에서 이전 내용을 삭제
use local
db.oplog.rs.drop()
db.me.drop()
db.replset.election.drop()
db.replset.minvalid.drop()
db.startup_log.drop()Replset 모음은 삭제할 수 없으므로 필요한 ID로 제거하십시오.
db.system.replset.remove({ "_id" : "your_replsetname"})필요한 크기가 50GB 인 새 oplog를 만듭니다.
db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )또한 mongod.conf 파일에서 oplog 크기를 MB 단위로 지정할 수 있습니다 (예 : 50GB의 경우 429496MB).
replication:
oplogSizeMB: 429496도움이 되었기를 바랍니다 !!!
편집하다:
코멘트에서 Nicholas Tolley Cottrell이 언급했듯이. MongoDB 버전 3.6 에서는 재시작하지 않고 런타임에 oplog 크기를 변경할 수 있습니다.
현재 oplog 크기 확인
use local
db.oplog.rs.stats().maxSizeoplog 크기를 10GB로 변경하려면
db.adminCommand({replSetResizeOplog: 1, size: 10000})