MongoDB Primary Member 선출을 못할 때 복구하는 방법

Replica Set은 과반수의 멤버가 정상일 때, Primary role을 갖는 Member를 선출할 수 있다. 즉, 과반수를 채우지 못하면 Write는 불가능하고 Read만 가능한 상태가 된다. 위의 예시처럼 3개중 1개 멤버가 죽었을 때는 문제가 없지만, 2개의 멤버가 죽으면 Primary Role이 없다. 또한 과반수는 Voting 멤버를 기준으로한다.

4개의 멤버를 기준으로 했을 때 과반수는 3개이다. 하지만, MongoDB의 선출 알고리즘은 voting member를 기준으로하기 때문에 Replica Set 구성이 4개이더라도 3개 멤버에서만 선출작업을 진행한다. 그래서 위의 이미지처럼 voting멤버 3개 중 과반수인 2개 멤버만 살아 있다면 Primary를 선출한다. 참고로 MongoDB는 최대 7개의 Voting 멤버를 부여할 수 있고 최대 50개의 멤버를 Replica Set으로 구축할 수 있다.

과반수 테스트 (3 Member)

상태 확인

rs_1 [direct: primary] test> rs.status().members
[
  {
    _id: 0,
    name: '__HOST1__:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 74756,
    optime: { ts: Timestamp({ t: 1683264809, i: 1 }), t: Long("11") },
    optimeDurable: { ts: Timestamp({ t: 1683264809, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:33:29.000Z"),
    optimeDurableDate: ISODate("2023-05-05T05:33:29.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    lastHeartbeat: ISODate("2023-05-05T05:33:31.355Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:33:31.355Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '__HOST3__:27017',
    syncSourceId: 2,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 1,
    name: '__HOST2__:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 948956,
    optime: { ts: Timestamp({ t: 1683264809, i: 1 }), t: Long("11") },
    optimeDurable: { ts: Timestamp({ t: 1683264809, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:33:29.000Z"),
    optimeDurableDate: ISODate("2023-05-05T05:33:29.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    lastHeartbeat: ISODate("2023-05-05T05:33:32.284Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:33:31.539Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '__HOST3__:27017',
    syncSourceId: 2,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 2,
    name: '__HOST3__:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 1814026,
    optime: { ts: Timestamp({ t: 1683264809, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:33:29.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:33:29.680Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1682315664, i: 1 }),
    electionDate: ISODate("2023-04-24T05:54:24.000Z"),
    configVersion: 7,
    configTerm: 11,
    self: true,
    lastHeartbeatMessage: ''
  }
]

3개의 멤버가 정상인 상태이고 1개의 Primary와 2개의 Secondary로 구성되어 있다.

rs_1 [direct: primary] test> rs.conf()
{
  _id: 'rs_1',
  version: 7,
  term: 11,
  members: [
    {
      _id: 0,
      host: '__HOST1__:27017',
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: {},
      secondaryDelaySecs: Long("0"),
      votes: 1
    },
    {
      _id: 1,
      host: '__HOST2__:27017',
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: {},
      secondaryDelaySecs: Long("0"),
      votes: 1
    },
    {
      _id: 2,
      host: '__HOST3__:27017',
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: {},
      secondaryDelaySecs: Long("0"),
      votes: 1
    }
  ],
  protocolVersion: Long("1"),
  writeConcernMajorityJournalDefault: true,
  settings: {
    chainingAllowed: true,
    heartbeatIntervalMillis: 2000,
    heartbeatTimeoutSecs: 10,
    electionTimeoutMillis: 10000,
    catchUpTimeoutMillis: -1,
    catchUpTakeoverDelayMillis: 30000,
    getLastErrorModes: {},
    getLastErrorDefaults: { w: 1, wtimeout: 0 },
    replicaSetId: ObjectId("63ae7ae46d30e0748a16a7d3")
  }
}

Replica Set의 멤버 상태를 보면, 모두 아래와 같은 설정을 갖는다.

hidden: false
priority: 1
votes: 1

현재는 Read와 Write 모두 가능한 상태이다.

1 Member Down

rs_1 [direct: secondary] test> db.shutdownServer()

Secondary 멤버 하나를 죽이고 다시 상태를 확인한다.

rs_1 [direct: primary] test> rs.status().members
[
  {
    _id: 0,
    name: '__HOST1__:27017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:39:39.694Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:39:39.694Z"),
    lastHeartbeat: ISODate("2023-05-05T05:40:07.369Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:39:47.359Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to __HOST1__:27017 (__IP1__:27017) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 1,
    name: '__HOST2__:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 949352,
    optime: { ts: Timestamp({ t: 1683265199, i: 1 }), t: Long("11") },
    optimeDurable: { ts: Timestamp({ t: 1683265199, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:39:59.000Z"),
    optimeDurableDate: ISODate("2023-05-05T05:39:59.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:39:59.695Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:39:59.695Z"),
    lastHeartbeat: ISODate("2023-05-05T05:40:08.317Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:40:07.622Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '__HOST3__:27017',
    syncSourceId: 2,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 2,
    name: '__HOST3__:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 1814421,
    optime: { ts: Timestamp({ t: 1683265199, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:39:59.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:39:59.695Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:39:59.695Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1682315664, i: 1 }),
    electionDate: ISODate("2023-04-24T05:54:24.000Z"),
    configVersion: 7,
    configTerm: 11,
    self: true,
    lastHeartbeatMessage: ''
  }
]

0번 멤버는 연결할 수 없는 상태이지만, 1번과 2번은 각각 살아있고 Secondary와 Primary role을 갖는다.

2 Member Down

rs_1 [direct: secondary] test> db.shutdownServer()

동일하게 다른 Secondary Member를 죽인다. 그리고 상태를 다시 확인한다.

rs_1 [direct: secondary] test> rs.status().members
[
  {
    _id: 0,
    name: '__HOST1__:27017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:39:39.694Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:39:39.694Z"),
    lastHeartbeat: ISODate("2023-05-05T05:44:03.013Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:39:47.359Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to replica-50-001-mongo-v-jp2v-dev.lineinfra-dev.com:20011 (10.241.152.125:20011) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 1,
    name: '__HOST2__:27017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:43:19.702Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:43:19.702Z"),
    lastHeartbeat: ISODate("2023-05-05T05:44:02.860Z"),
    lastHeartbeatRecv: ISODate("2023-05-05T05:43:29.690Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to replica-50-002-mongo-v-jp2v-dev.lineinfra-dev.com:20011 (10.241.152.126:20011) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11
  },
  {
    _id: 2,
    name: '__HOST3__:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 1814656,
    optime: { ts: Timestamp({ t: 1683265409, i: 1 }), t: Long("11") },
    optimeDate: ISODate("2023-05-05T05:43:29.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T05:43:29.702Z"),
    lastDurableWallTime: ISODate("2023-05-05T05:43:29.702Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 7,
    configTerm: 11,
    self: true,
    lastHeartbeatMessage: ''
  }
]

3개의 멤버 중 2개의 멤버가 죽은 상태이다. Replica Set의 상태를 확인했을 때, Primary는 없고 Secondary만 남아있는 상황이다. 3개의 과반수인 2개의 멤버가 정상이지 못하여 Primary를 선출하지 못하고 있다. 실제 3개의 멤버로 운영되는 MongoDB라고 가정했을 때, 모든 멤버가 죽는 경우는 의외로 대량의 부하가 발생했을 때 가능하지만, 2개의 멤버만 죽는 경우는 매우 드물다. 하지만, 언제 어떻게 문제가 발생할지 우리는 모르기 때문에 실제로 과반수를 채우지 못하여 Primary Member가 없는 경우 어떻게 처리해야하는지 미리 알아보자.

임시적 Standalone 복구

Replica Set 구성은 모든 멤버가 동일한 데이터를 들고 있다. Read/Write 모두 정상적으로 작동하기 위해서는 과반수가 정상이어야한다. 그럼 위의 문제를 해결할 수 있는 방법은 2가지이다.

멤버를 늘리거나
멤버를 줄이거나

멤버를 늘릴 경우, MongoDB 설치까지 완료된 즉, 바로 사용가능한 준비된 서버가 있어야하는데... 서버가 있다고하더라도 데이터 양에 따라 복구 시간 차이가 크게 날 것이다. 데이터가 적으면 Initial Sync로 금방 복제를 따라갈 수 있지만... 대량의 데이터일 경우, Initial Sync는 당연하고 백업을 복사하는 방식도 크기에 따라 비례적으로 오래 걸릴 것이다.

Primary 선출을 못하는 장애는 Write를 할 수 없는 매우 긴급한 장애로, 응급처치성으로 일단 모든 기능이 정상 작동하도록 조취하는 것이 중요하다. 그래서 멤버를 늘리는 것 보다 멤버를 줄여서 일시적으로 1개의 멤버를 갖는 Standalone 형태로 복구하는 것이 가장 빠를 것이다. 즉, 3개 멤버중 2개 멤버를 Replica Set에서 제거하는 방법이다. 단 아래와 같은 문제가 발생할 수 있다는 점은 고려해야한다.

기존 Write 트래픽과 모든 Read가 하나의 서버에서 감당할 수 있어야한다. Read가 여러대의 Secondary로 분산되고 있었고 Write도 많은 서비스였다면 최악의 경우, 하나의 서버에서 모든 트래픽을 감당하지 못하고 남은 서버 하나도 죽을 수 있다.
Application단에서 Read Preference가 secondary였다면 Primary가 하나만 남았을 때, Write는 되겠지만 오히려 반대로 Read가 안될 수 있다.

자 그럼 위의 고려사항을 배제하고... 복구하는 작업을 진행하려는데...

rs_1 [direct: secondary] test> rs.remove('__HOST1__:27017')
MongoServerError: New config is rejected :: caused by :: replSetReconfig should only be run on a writable PRIMARY. Current state SECONDARY;

위에 처럼 remove 명령으로 Replica Set Member를 제거하는 방식이 1차적으로 생각나겠지만... 명령 수행이 안된다. 이유는 Secondary에서 수행했기 때문에 발생하는 문제이다. 빠른 복구가 필요한 응급 상황에서 내가 예상한대로 진행되지 않으면... 일단 심장부터 멎는 기분이고 소름 쫙 끼치면서 매우 당황스러울 것이다. ㅎㅎ 아래 방법으로 처리하자.

# 현재 살아있는 멤버의 배열 위치를 확인한다.
rs_1 [direct: secondary] test> rs.conf().members

rs_1 [direct: secondary] test> conf = rs.conf()
rs_1 [direct: secondary] test> conf.members = [conf.members[2]]
rs_1 [direct: secondary] test> rs.reconfig(conf, {force: true})

rs_1 [direct: primary] test> rs.status().members
[
  {
    _id: 2,
    name: '__HOST3__:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 1817126,
    optime: { ts: Timestamp({ t: 1683267912, i: 1 }), t: Long("15") },
    optimeDate: ISODate("2023-05-05T06:25:12.000Z"),
    lastAppliedWallTime: ISODate("2023-05-05T06:25:12.021Z"),
    lastDurableWallTime: ISODate("2023-05-05T06:25:12.021Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1683267821, i: 1 }),
    electionDate: ISODate("2023-05-05T06:23:41.000Z"),
    configVersion: 225221,
    configTerm: -1,
    self: true,
    lastHeartbeatMessage: ''
  }
]

우회하는 방식으로 reconfig의 force 옵션을 사용하면 된다. 코드를 대략적으로 설명하자면, rs.conf() 명령으로 살아있는 멤버의 배열 위치를 확인하고... members 배열에 살아 있는 seconday 멤버 하나를 넣고 강제로 Replica Set을 재설정하는 방법이다. 이렇게 secondary 멤버만 있는 상태에서도 임시적으로 standalone 형태로 배포형태를 변경할 수 있다. 단, force가 안전한 명령은 아니기 때문에 지금처럼 응급처치가 필요한 상황에서만 사용하는 것이 좋다.

저작자표시 비영리 변경금지

마이자몽

MongoDB Primary Member 선출을 못할 때 복구하는 방법

과반수 테스트 (3 Member)

상태 확인

1 Member Down

2 Member Down

임시적 Standalone 복구

댓글

티스토리툴바

MongoDB Primary Member 선출을 못할 때 복구하는 방법

과반수 테스트 (3 Member)

상태 확인

1 Member Down

2 Member Down

임시적 Standalone 복구

관련글

댓글

티스토리툴바