MongoDB Internals

글 : 이승용

복제 기반의 독립 서버의 설치는 적어도 3개의 mongod가 설치되어야 한다. 하지만, MongoDB는 3개의 mongod를 완전하게 사용하도록 추천하고 있지만, 단순히 복제만을 수행하기를 원하는 사람들을 위해, arbiter 개념을 두고 있다. Arbiter는 mongod로써의 데이터 저장 기능을 가지지 않지만, 마스터 서버 장애 시에 마스터 서버 선출을 위한 투표권을 행사할 수 있는 서버이다. 따라서, 마스터 서버의 장애 발생 이외에는 arbiter는 DB서버로의 행위를 수행하지 않는다.

복제 기반의 독립 서버의 장애 처리를 위해 [그림 5-1]과 같은 구조로 시스템을 구축한다. 3개의 mongod를 설치하고, master 서버로 첫 번째 서버(포트 10001)으로 설정한 구성도이다. 이를 위해 다음과 같은 순서로 설치를 수행한다.[1]
 

 

./mongod --dbpath /data/example/firstset1 --port 10001 --replSet firstset
./mongod --dbpath /data/example/firstset2 --port 10002 --replSet firstset
./mongod --dbpath /data/example/firstset3 --port 10003 --replSet firstset

상기와 같이 3대의 mongod를 수행하고 난 다음에 MongoDB 클라이언트인 mongo를 다음과 같이 기동한다.

./mongo localhost:10001/admin

그러면 [그림 5-1]과 같이 클라이언트가 monod 포트 10001번에 접속한 상태가 된다. 여기서 runCommand를 이용하여 다음과 같이 수행한다.

> db.runCommand({"replSetInitiate" : {"_id" : "firstset", "members" : [{"_id" : 1, "host" : "localhost:10001"}, {"_id" : 2, "host" : "localhost:10002"}, {"_id" : 3, "host" : "localhost:10003"}]}})
{
    "info" : "Config now saved locally.  Should come online in about a minute.",
    "ok" : 1
}
>
>

[그림 5-1]과 같이 설정된 복제 독립 서버는 클라이언트와 포트 10001번 MongoDB와 통신하며, 데이터를 적재한다. 포트 10001번 MongoDB에 적재된 데이터는 복제 정책에 의해 포트 10002, 10003번 MongoDB에 복제 저장된다.[2]

복제 독립 서버의 장애는 마스터 서버 장애와 슬레이브 서버 장애로 구분된다. 다음의 규칙을 잘 이해하자.

 가)   슬레이브 서버의 장애는 마스터 서버에 영향을 주지 않으며, 마스터 선출을 위한 투표를 수행하지 않는다.

나)   같은 복제 집합을 구성하는 서버들 중에서 마스터가 살아 있으면, 슬레이브 서버 장애 유무와 관계 없이 복제 집합은 유지된다. 다만, 살아있는 투표권이 과반수를 넘지 않은 상태의 마스터는 마스터 지위를 일정시간이 지난 이후에 포기한다.

다)   마스터 서버의 장애가 발생하면 슬레이브 서버들이 마스터 선출을 위한 투표를 진행한다.

라)   마스터 서버의 투표를 위해서는 적어도 2개의 서버가 존재하여야 한다. 따라서, 한 개의 슬레이브는 마스터로 선출될 수 없다.

 

 
[그림 5-2]의 경우는 규칙 (다)와 (라)에 의해 슬레이브 서버가 2개 이상이므로 투표가 투표를 시작한다. 시작된 투표는 투표 알고리즘에 의해 두 개의 서버 중 한 개가 마스터로 선출된다. [그림 5-2]는 포트 10002번 서버가 마스터로 선출된 경우를 보여준다. 여기서 중요한 점은 포트 10001번으로 연결된 클라이언트는 마스터 장애로 인해 포트 10001번과의 연결이 단절된다. 따라서, 클라이언트는 스스로 마스터를 찾아 새롭게 선출된 마스터로 연결을 시도하여야 한다.MongoDB의 복제 정책은 Active-Active 방식이 아니다. 따라서, 슬레이브 서버는 read-only만 가능하기 때문에, 데이터를 저장하지 않는다. 즉, 복제 독립 서버의 구성은 마스터 서버의 back-up으로 사용되는 Master-Slave 방식으로 사용된다.[그림 5-3]은 복제 독립 서버 장애 상황 중에서 슬레이브 서버만 장애가 발생된 시나리오다. 두 개의 슬레이브 서버가 장애가 발생하였지만, 마스터 서버가 계속 동작하고 있어서, 투표도 발생되지 않고, 클라이언트는 복제 집합에 데이터를 계속 적재할 수 있다. 장애가 발생하여도 시스템은 안전한 상태이다.

하지만, 총 3대의 서버 중에서 2대의 슬레이브 서버가 장애가 발생한 경우이므로, 서버의 과반수가 장애가 발생했다. 이 시점에서 MongoDB는 마스터의 투표권을 조사한다. 살아있는 마스터의 투표권이 전체 3개 서버가 가지고 있던 투표권 보다 과반수를 넘으면 시스템은 안전한 상태로 판단하고, 과반수가 넘지 않으면 마스터는 스스로의 마스터 지위를 포기한다. 이러한 증상은 [그림 5-3]의 세 번째 상태로 전이된 후, 약 25~30초 정도면 발생하며, 이를 마스터 포기라 한다.
 

 
[그림 5-4]는 마스터 서버가 장애가 발생하고 슬레이브 서버들 사이에서 투표를 통해 새로운 마스터 서버를 선출하였고, 다시 슬레이브 서버에서 장애가 발생한 상태이다. [그림 5-3]과 같이 두 개의 서버가 장애가 발생했음에도 마스터가 계속 동작하고 있어서 시스템은 안전한 상태이다. 다만, [그림 5-3]과 다르게 마스터 선출하기 위한 투표하는 동안 마스터 서버가 부재 기간이 발생하여 데이터 삽입이 발생되지 않는다. 또한 클라이언트 역시 새롭게 선출된 마스터로의 연결을 수행하여야 한다. [그림 5-4]도 마찬가지로 마스터의 투표권이 과반수를 넘지 않은 상태라면 25초 이후에 마스터 포기가 발생한다.
 

 
[그림 5-5]는 [그림 5-4]와 같이 초반에 마스터 서버의 장애가 발생하여 투표를 통해 새로운 마스터를 선출하였다. 하지만, 두 번째 발생한 장애 서버가 마스터인 경우는 앞에서 다룬 두 가지 경우와 같이 두 개의 서버가 장애가 발생했음에도 불구하고 마지막으로 생존해 있는 서버가 슬레이브이기 때문에 규칙 (라)에 의해 새로운 마스터를 선출할 수 없기 때문에, 복제 집합 전체 장애가 발생한다.
 

 

다음 글 : 복제 독립 서버 복원