2015년 2월 16일 월요일

몽고 레플리케이션 싱크에러


몽고에러

레플리케이션이나 샤딩에러


싱크 에러

  1. 몽고에 에러가 발생했을 경우 마스터 서버로 간다.
몽고가 있는 서버로 가서
ps -ax | grep mongo
 8373 ?        Sl   608:30 /usr/bin/mongod -f /etc/mongod.conf
 8465 ?        Sl   768:49 /usr/bin/mongod -f /etc/mongod-config-server.conf
11927 pts/2    S+     0:00 grep mongo
26213 ?        Sl   852:33 /usr/bin/mongos -f /opt/thirdparty/mongos_test.conf
  1. 컨피그를 확인해서 몽고스를 통하지 않고 직접 마스터의 포트로 접속
    ps -ax | grep mongo
     port = 숫자
    
  2. 마스터에서 레플 또는 샤딩 상태를 확인
    -인증을 받고
    use admin
    db.auth(id,pw)
    rs.status()
shard-a:PRIMARY> rs.status()
{
    "set" : "shard-a",
    "date" : ISODate(""),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "ip1,
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 9658337,
            "optime" : Timestamp(),
            "optimeDate" : ISODate(""),
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "ip2",
            "health" : 1,
            "state" : 3,
            "stateStr" : "RECOVERING",
            "uptime" : 720382,
            "optime" : Timestamp(),
            "optimeDate" : ISODate(""),
            "lastHeartbeat" : ISODate(""),
            "lastHeartbeatRecv" : ISODate(""),
            "pingMs" : 0,
            "lastHeartbeatMessage" : "still syncing, not yet to minValid optime 54e1c1a7:34",
            "syncingTo" : "ip1"
        },
        {
            "_id" : 2,
            "name" : "ip3",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 720395,
            "lastHeartbeat" : ISODate(""),
            "lastHeartbeatRecv" : ISODate(""),
            "pingMs" : 0
        }
    ],
    "ok" : 1
}
  1. 문제가 있다면
  • 위의 경우는 레플리케이션에서 싱크가 되어있지 않다.
  • 해당 레플리케이션 서버로 이동
  • 1, 2번 을 적용해서 로깅 위치 확인
  • 로깅으로 가서 해당 날짜 사유 확인
  1. 싱크관련 에러
    [rsBackgroundSync] replSet syncing to: masterIP
    [rsBackgroundSync] replSet error RS102 too stale to catch up, at least from masterIP
    [rsBackgroundSync] replSet our last optime : 
    [rsBackgroundSync] replSet oldest at masterIP :
    [rsBackgroundSync] replSet See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember
    [rsBackgroundSync] replSet error RS102 too stale to catch up
    [rsBackgroundSync] replSet RECOVERING
    
  • oplog 의 사이즈를 넘어가면 위와 같은 에러가 발생한다 디폴트 사이즈는?
    디폴트 크기는 사용가능 한 디스크의 5%를 몽고 디비가 설정한다.
    권장사항은 최소 디비에 적일 양의 24시간을 버틸 정도로 설정해야 한다.
    실 어드민은 가능한 최대한 많이를 추천한다.(capped collection 이기 때문에 덥어쓰면 복구가 안되기 때문이다.)
  • 그렇다면 어디서 로그 크기를 확인하는가?
    버전 2.4 db.printSlaveReplicationInfo()
    버전 2.6 rs.printReplicationInfo()

  • 최초에 바꾸기
    replication.oplogSizeMB
  • 나중에 바꾸기
    The way the sync works is secondary notes a place in the oplog on the
    primary, then starts copying all the data over.
    http://docs.mongodb.org/manual/tutorial/change-oplog-size/
    db.runCommand( { create: “oplog.rs”, capped: true, size: (2 1024 1024 * 1024) } )

시간 에러

  1. 서버 시간이 다를 경우 mongos 에서 connection 접속시 에러가 발생할수 있다.
    ntp 를 사용해서 서버끼리 시간을 동기화 해주고 cron에 추가해서 배치잡으로 돌리자.