생산에서 MongoDB 샤딩 오류

Question

우리는 node + mongodb를 사용하여 채팅 모듈에 mongodb sharding 개념을 구현했습니다.

MongoDB Sharding Configuration 
=============================== 
Shard1 = PRIMARY + SECONDARY + ARBITER 
Shard2 = PRIMARY + SECONDARY + ARBITER 
Config 
Mongos 

세부 사항 다음과 같이 우리는 오늘 아침에 그것을 얻었다. 그러나 우리는 어떻게이 문제를 해결할 수 있는지 알지 못합니다.

이 문제를 해결할 수있는 방법을 알려주세요.

"에 errmsg":

"errmsg를"을 "이 오류 findcommonpoint 다시 시도하기 전에 잠시 대기 롤백"

data2:PRIMARY> rs.status() 
{ 
    "set" : "data2", 
    "date" : ISODate("2012-07-27T04:30:29Z"), 
    "myState" : 1, 
    "members" : [ 
     { 
      "_id" : 0, 
      "name" : "50.52.108.16:20001", 
      "health" : 1, 
      "state" : 9, 
      "stateStr" : "ROLLBACK", 
      "uptime" : 322, 
      "optime" : { 
       "t" : 1343361602000, 
       "i" : 155 
      }, 
      "optimeDate" : ISODate("2012-07-27T04:00:02Z"), 
      "lastHeartbeat" : ISODate("2012-07-27T04:30:29Z"), 
      **"errmsg" : "rollback 2 error findcommonpoint waiting a while before trying again"** 
     }, 
     { 
      "_id" : 1, 
      "name" : "50.52.108.17:20002", 
      "health" : 1, 
      "state" : 1, 
      "stateStr" : "PRIMARY", 
      "optime" : { 
       "t" : 1343363429000, 
       "i" : 7 
      }, 
      "optimeDate" : ISODate("2012-07-27T04:30:29Z"), 
      "self" : true 
     }, 
     { 
      "_id" : 2, 
      "name" : "50.52.108.17:20003", 
      "health" : 1, 
      "state" : 7, 
      "stateStr" : "ARBITER", 
      "uptime" : 10880311, 
      "optime" : { 
       "t" : 0, 
       "i" : 0 
      }, 
      "optimeDate" : ISODate("1970-01-01T00:00:00Z"), 
      "lastHeartbeat" : ISODate("2012-07-27T04:30:28Z") 
     } 
    ], 
    "ok" : 1 
} 

data1:PRIMARY> rs.status() 
{ 
    "set" : "data1", 
    "date" : ISODate("2012-07-27T04:30:17Z"), 
    "myState" : 1, 
    "members" : [ 
     { 
      "_id" : 0, 
      "name" : "50.52.108.17:10001", 
      "health" : 1, 
      "state" : 3, 
      "stateStr" : "RECOVERING", 
      "uptime" : 35, 
      "optime" : { 
       "t" : 1343320338000, 
       "i" : 3 
      }, 
      "optimeDate" : ISODate("2012-07-26T16:32:18Z"), 
      "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z"), 
      "errmsg" : "error RS102 too stale to catch up" 
     }, 
     { 
      "_id" : 1, 
      "name" : "50.52.108.16:10002", 
      "health" : 1, 
      "state" : 1, 
      "stateStr" : "PRIMARY", 
      "optime" : { 
       "t" : 1343363417000, 
       "i" : 30 
      }, 
      "optimeDate" : ISODate("2012-07-27T04:30:17Z"), 
      "self" : true 
     }, 
     { 
      "_id" : 2, 
      "name" : "50.52.108.16:10003", 
      "health" : 1, 
      "state" : 7, 
      "stateStr" : "ARBITER", 
      "uptime" : 10880162, 
      "optime" : { 
       "t" : 0, 
       "i" : 0 
      }, 
      "optimeDate" : ISODate("1970-01-01T00:00:00Z"), 
      "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z") 
     } 
    ], 
    "ok" : 1 
} 

Kumaran

"을 잡을 오류 RS102가 너무 부실"

Answer 1

보조기가 매우 오랜 기간 동안 다운 된 것처럼 보이며 이제는 기본과 동기화 될 수 없습니다. 이 동기화는 oplog가 2 차 가동 중단 동안 1 차로가는 모든 쓰기를 포함 할 것을 요구합니다. 그 후,

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

oplog를 늘리는 것이 좋습니다 보조가 너무 오래 다운 된 경우, 레코드가 그것이 "출장"collection.You이기 때문에 oplog에서 출시되었을 수는 전체 resyc을 할 필요가 미래에 비슷한 상황을 피하기 위해 크기.

Answer 2

Aafreen의 대답은 정확하며 조언은 좋습니다.

oplog 크기를 조정할 때 RS102가 다시 발생하지 않도록주의하십시오.

oplog 크기는 변경하는 데이터의 양과 빈도에 따라 달라집니다. 이것은 응용 프로그램에 매우 의존적입니다 (일반적인 쓰기 패턴이 무엇인지 생각해보십시오). 당신은 기본적으로 오류 또는 유지 관리 창에서 복구 할 수있는 가장 많은 시간을 여러 번하는 oplog를 원합니다.

Oplog

oplog는 MongoDB에 저장된 데이터를 수정하는 작업을 모두 저장하는 캡핑 된 집합이다. 복제본 집합의 모든 구성원은 데이터베이스의 현재 상태를 유지 관리 할 수있는 복제본을 가지고 있습니다. 당신이 oplogSize 옵션으로 oplog의 크기를 수정하지 않는 한,로 될 oplog의 기본 크기는 다음과 같습니다

• 64 비트 Linux, Solaris 및 FreeBSD의 시스템의 경우, MongoDB를가의 5 %를 할당합니다 oplog에 사용 가능한 디스크 공간.

  이 금액이 기가 바이트보다 작 으면 MongoDB는 1 기가 바이트의 공간을 할당합니다.

• 64 비트 OS X 시스템의 경우 MongoDB는 oplog에 공간에 183 메가 바이트의 공간을 할당합니다.

  32 비트 시스템의 경우 MongoDB는 oplog에 에 약 48 메가 바이트의 공간을 할당합니다.

난 당신이 쓰기를 많이 수행하는 경우 말 당에는 공식, 그러나, 없다, 위에서 언급 한 바와 같이 (인서트/삭제/업데이트) 다음 (5 % 이상) 큰 oplog을 할 수 있습니다 경우 반면, 그것은 주로 읽고, 당신은 5 % 미만으로 도망 칠 수 있습니다, 그것은 정말로 당신의 앱에 달려 있습니다.

여기에 조금 더 일을 설명하는 데 도움이와 나는 또한 Replication Fundamentals document를 읽고 추천 할 수 oplog 크기 다른 introductory link,입니다.

기본에서 oplog가 가장 중요하며 복제본 집합의 모든 oplog가 동일한 크기 인 것이 좋습니다.