MongoDB의 복제 동기화 및 마스터 선출
글 : 이승용
MongoDB의 복제 시스템에서 대해서는 앞 절에서 살펴보았다. 복제는 시스템의 Fail-Over를 제공하기 위한 분산시스템의 핵심 기술로 자리잡고 있다. 복제 시스템은 master가 죽더라도 slave가 master의 역할을 대행할 수 있도록 데이터의 동기화에 많은 부분을 할애하고 있다. 복제시스템은 master-master와 master-slave 형식으로 구성할 수 있다. 일반적으로 복제 시스템에서는 master에서만 쓰기 연산이 수행되고, 읽기 연산은 master와 slave 모두에서 수행될 수 있다. 따라서 master는 쓰기 연산을 통해 적재된 데이터를 가장 빠른 시간 안에 slave에 전달하여야 한다. MongoDB는 master-slave 방식의 복제 동기화를 수행한다. [그림 2-2]를 살펴보자.
[그림 2-2]의 MongoDB는 한 개의 master와 두 개의 slave로 구성된 복제 집합replica set을[1]구성하고 있다. MongoDB는 복제 집합으로 구성된 각각의 노드는 자신을 제외한 다른 노드들이 죽었는지 살았는지를 검사하기 위해 [그림 2-2]과 같은 heartbeat를 사용한다. MongoDB의 heartbeat는 2초 단위로 수행되며, heartbeat을 받은 서버는 자신의 상태 코드를 heartbeat을 요청한 서버에 보내준다. [표 2]는 heartbeat을 통해 전달된 서버 상태 코드를 보여준다.
상태 코드 | 내용 |
RS_STARTUP | 서버가 시작 중이거나 또는 복제 집합의 초기화를 수행하는 상태 |
RS_STARTUP2 | 초기화를 위한 복제 환경 로드는 완료하였지만, primary[2]를 선출하는 상태 |
RS_PRIMARY | 서버 자신이 primary 상태 |
RS_SECONDARY | 서버 자신이 secondary[3] 상태 |
RS_RECOVERING | 서버가 secondary로 상태가 변경되기 전에 primary로부터 복제 동기화를 수행하는 상태 |
RS_ROLLBACK | 서버가 secondary로 상태가 변경되기 전에 primary로부터 복제 동기화를 수행하는 상태로, 서버가 primary보다 더 많은 데이터를 가지고 있어서 primary 상태로 저장된 데이터로 되돌리는 상태 |
RS_FATAL | 서버가 복제 집합 안에서 네트워크 단절과 같이 완전한 offline 상태는 아니지만, 심각한 문제가 발생한 상태 |
RS_SHUNNED | 서버가 어떠한 복제 집합에도 속하지 않은 상태 |
Master 서버의 heartbeat는 항상 복제 집합을 구성하고 있는 노드 개수의 과반수만큼을 유지하고 있어야 한다. 만약 master 서버가 과반수의 heartbeat을 가지고 있지 않다면, 서버는 slave로 변환되며, 복제 집합은 master 부재에 따른 투표를 시행한다. MongoDB의 master 선출과정은 다른 Google의 PAXSOS와 유사하다. 단지 차이점이 있다면, master가 될 수 있는 자격 조건에 대한 옵션 priority와 votes를 가지고 있다는 차이점이 있다. Priority는 자신이 master가 될 수 있는 우선 순위를 나타내는 것으로 priority가 높은 서버가 master가 될 가능성이 높다. 만약 priority가 0이라면 이는 자신 자신은 master로 설정할 수 없음을 나타낸다. 또한 votes는 투표할 수 있는 개수를 의미하는 것으로, master는 자신을 포함한 복제 집합의 노드 개수의 과반수 투표를 가져야 한다. 그렇다면, votes와 priority와의 차이점은 무엇인가? Votes는 투표권을 말한다. 즉, 한 복제 집합에서 보유한 투표권은 각각의 노드가 가지고 있는 투표권을 모두 더한 것을 말한다. 아무런 값도 설정하지 않았다면 투표권은 한 노드 당 한 개의 값을 가질 것이다. 예를 들어 보자. 총 4개의 노드로 구성된 복제 집합이 [그림 2-3]과 같이 구성되었다고 가정하자.
- 복제 집합에서 과반수 노드들과 연결을 유지하는 있어야 한다.
- Priority가 0보다 커야 한다.
- 서버가 유지하고 있는 optime이 연결될 수 있는 다른 노드들의 optime 중에서 가장 최신 opime을 기준으로 10초 이내에 있어야 한다.
복제 집합의 노드는 위 세가지 조건을 만족한다면, master 후보군이 되며, 자신이 master임을 인지하고, 다음과 같은 절차를 통해 투표를 수행한다.
- 자신의 master가 될 수 있는 서버인지 판단하고, master가 될 수 있는 서버는 다음과 같은 일을 수행한다.
- 자신이 master임을 인지하고 아주 짧은 시간 동안 기다린다.
- 자신이 master임을 다른 노드에 통보한다.
- 만약, 다른 노드들로부터 전달받은 메시지가 있다면, 자신의 priority와 비교하여 낮거나 또는 자신의 optime 보다 최신의 상태가 아니면 거부권을 발동한다.[5]
- 만약, 거부권을 행사했다면, 자신의 master가 될 수 있다는 것이므로, 거부권을 행사한 서버는 YES를 과반수 이상 받아야만 한다.
- 만약, 2)번에서 거부권을 행상하지 않은 서버는 자신이 master의 자격이 없다는 것을 의미하는 것으로, 1)번에서 발송한 메시지에 대해 1분안에 거부권을 모두 받아야만 하며, 거부권을 모두 수신한 서버는 투표를 완료하게 된다.[6]
이전글 : MongoDB의 복제 시스템
다음글 : MongoDB의 복제 한계
[1] 복제 집합이란 한 개의 master를 중심으로 master를 바라보고 있는 slave들을 묶어 놓은 시스템을 말한다. 샤딩sharding 또는 분할이 적용된 분산시스템에서는 분할된 단위로 복제가 이루어지기 때문에 여러 개의 복제 집합이 존재한다.
[2] Master와 primary는 같이 혼용되어 사용된다.
[3] Slave와 secondary가 같이 혼용되어 사용된다.
[4] 만약, priority와 votes가 다 높은 시스템을 구성한다면, 해당 노드가 죽었을 경우에 이 복제 집합은 master가 없는 read-only가 된다.
[5] NO로 응답을 보낸다.
[6] Master 선출 과정은 최대 5분까지 주어지며, 5분을 초과할 경우 master 선출은 취소된다.
[7] 수퍼맨이 태어난 행성이 크립톤 행성이다.