RS102 MongoDB on ReplicaSet

Question

4 개의 서버로 구성된 복제 세트를 설정했습니다.

테스트 목적으로 GridFS를 사용하여 최대 150 억 개의 사진 행을 데이터베이스에 채울 수있는 스크립트를 작성했습니다. 내 사진은 약 15KB입니다.

replSet error RS102 too stale to catch up, at least from 192.168.0.1:27017 

: 몇 시간 후, 약 50 백만 열이 후

(?!이 작은 파일을 gridfs을 사용하는 문제가되지 않습니다)하지만 나는 로그이 메시지가 있었다

그리고 여기가 replSet 상태입니다 :

rs.status(); 
{ 
"set" : "rsdb", 
"date" : ISODate("2012-07-18T09:00:48Z"), 
"myState" : 1, 
"members" : [ 
    { 
     "_id" : 0, 
     "name" : "192.168.0.1:27017", 
     "health" : 1, 
     "state" : 1, 
     "stateStr" : "PRIMARY", 
     "optime" : { 
      "t" : 1342601552000, 
      "i" : 245 
     }, 
     "optimeDate" : ISODate("2012-07-18T08:52:32Z"), 
     "self" : true 
    }, 
    { 
     "_id" : 1, 
     "name" : "192.168.0.2:27018", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64770, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 2, 
     "name" : "192.168.0.3:27019", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64735, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 3, 
     "name" : "192.168.0.4:27020", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 65075, 
     "optime" : { 
      "t" : 1342539085000, 
      "i" : 3838 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:31:25Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:46Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    } 
], 
"ok" : 1 

세트 여전히 받고있다 datas,하지만 난 "DOWN"제 3 개 서버를 가지고 어떻게 datas를 삭제하고보다 (더 좋은 복구를 진행해야 다시 동기화 wh ich는 오래 걸리지 만 효과가 있을까요?)

특히 : 너무 폭력적인 스크립트로 인해 발생합니까? 프로덕션에서 거의 절대 발생하지 않는다는 것을 의미합니까?

Answer 1

전체 재 동기화를 수행하기 만하면됩니다. 보조에

을 수행 할 수 있습니다

1. 는 다시 시작
2. (하위 디렉토리 포함) DBPATH에있는 모든 데이터를 삭제 실패한 mongod
3. 을 중지하고 자동으로 자체

를 동기화합니다

here의 지침을 따르십시오.

귀하의 경우에는 보조자가 부실화되었습니다. 즉, 보조원 및 보조원의 공통점이 없습니다. 다양한 상태를 나타내는 document을보십시오. 기본 구성원에 대한 쓰기는 보조 노드에 복제되어야하고 보조 노드는 결국 부실 상태가 될 때까지 유지할 ​​수 없습니다. oplog의 크기를 조정해야합니다.

oplog 크기는 시간이 지남에 따라 삽입/업데이트되는 데이터의 양에 따라 다릅니다. 나는 당신에게 수 시간이나 심지어 수개월 동안 할 수있는 크기를 선택할 것입니다.

또한 어떤 O/S가 실행 중인지 잘 모르겠습니다. 그러나 64 비트 Linux, Solaris 및 FreeBSD 시스템의 경우 MongoDB는 사용 가능한 디스크 공간의 5 %를 oplog에 할당합니다. 이 금액이 기가 바이트보다 작 으면 MongoDB는 1 기가 바이트의 공간을 할당합니다. 64 비트 OS X 시스템의 경우 MongoDB는 oplog 및 32 비트 시스템에 183MB의 공간을 할당하므로 MongoDB는 oplog에 약 48MB의 공간을 할당합니다.

레코드의 크기와 몇 개를 원하십니까? 이 데이터 삽입이 일반적인 것이거나 단순히 테스트 한 것이 아닌지 여부에 달려 있습니다.

예를 들어, 1KB 문서의 경우 초당 2000 개의 문서를 사용하면 분당 120MB의 데이터가 제공되고 5GB 오 프 로그는 약 40 분 동안 지속됩니다. 즉, 보조 컴퓨터가 40 분 동안 오프라인 상태가되거나 그보다 더 뒤 떨어지는 경우 오래된 상태이고 전체 다시 동기화를 수행해야합니다.

복제본 내부 문서 here을 읽는 것이 좋습니다. 복제 세트에 4 명의 구성원이 있으므로 권장되지 않습니다. voting election (of primary) process에 대한 홀수가 있어야하므로 중재자를 추가하거나 보조 보조를 추가하거나 보조 보조를 제거해야합니다.

마지막으로 RS administration에 대한 자세한 문서가 있습니다.