복제 독립 서버 복원
글 : 이승용
앞 절에서 살펴본 복제 독립 서버에서의 장애가 발생하고 장애가 발생한 서버를 재 기동할 경우에 발생되는 상황들에 대해 고찰해 본다. 장애 발생 서버의 재 기동에는 다음과 같은 규칙이 적용된다.
가) 서버를 재 기동하기 위해서는 처음 기동시킨 서버 포트와 복제 집합을 동일하게 명시하여야 한다.
나) 재 기동된 서버는 마스터로 복원되기 힘들다.
[그림 5-6]은 [그림 5-4]의 마스터 서버 장애 이후에 장애가 발생한 서버를 재 기동한 상황을 보여준다. 상기 규칙에서와 같이 다시 복원된 서버가 기존에 마스터 서버라고 하여도 기동과 동시에 마스터 서버로 설정되지 않음을 보여준다. 앞의 규칙 중 나)번의 경우의 재 기동된 서버인 경우에 마스터로 복원되기 어렵다는 것은 마스터로 선출될 수 있는 조건은 최신 optime이 10초이내에 있어야 마스터로 선출될 수 있는데, 서버 장애가 발생하고 10초 이내에 서버를 재 기동하지 않았다면 재 기동된 서버는 마스터로 선출되지 않는다.
./mongod --dbpath /data/example/firstset1 --port 10001 --replSet firstset
[그림 5-6] 복제 독립 서버의 장애 서버 복원
[그림 5-6]에서의 재 기동된 서버를 다시 마스터로 설정하고 싶다면 reconfig()를 이용하여 복제 집합 서버의 priority를 조정한다. Priority를 별도 조정하지 않았다면, 모두 1.0의 값을 가지며, 이는 마스터 선출을 위한 투표권에 영향을 준다.
명령어 reconfig()는 마스터 서버에서만 사용된다. 따라서, 마스터를 변경하고 싶다면, 현 마스터 서버에서 새로운 마스터 서버의 priority를 조정한다. 앞선 복제 독립 서버와 포트 10001, 10002, 10003을 기동하였다고 가정한다. 그리고, 마스터 서버 포트 10001번을 죽이고, 새로운 마스터 서버 포트 10002가 선출되었다. 새로운 마스터와 서버 연결을 위해 다음과 같이 새로운 mongo 클라이언트를 기동한다.
./mongo localhost:10002 > cfg = rs.config() > cfg.member[0].priority = 2 > rs.reconfig(cfg)
상기와 같이 명령어를 수행한 결과는 아래와 같다. 첫 번째 명령어 rs.config()를 수행하면 현재 복제 집합의 설정 상태를 보여준다. 그리고, 원하는 서버 포트 10001의 priority를 2로 설정하고 난 뒤에 rs.reconfig(cfg)를 수행한다. 하기와 같이 접속한 서버 포트 10002는 마스터의 위치에서 슬레이브로 변경된 것을 알 수 있다.
[리스트 5-1] 복제 독립 서버에서의 마스터 서버 변경
PRIMARY> cfg = rs.conf()
{
"_id" : "firstset",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "localhost:10001"
},
{
"_id" : 2,
"host" : "localhost:10002"
},
{
"_id" : 3,
"host" : "localhost:10003"
}
]
}
PRIMARY> cfg.members[0].priority = 2
2
PRIMARY> rs.reconfig(cfg)
Wed Jun 6 19:49:22 DBClientCursor::init call() failed
Wed Jun 6 19:49:22 query failed : admin.$cmd { replSetReconfig: { _id: "firstset", version: 2, members: [ { _id: 1, host: "localhost:10001", priority: 2.0 }, { _id: 2, host: "localhost:10002" }, { _id: 3, host: "localhost:10003" } ] } } to: localhost:10002
Wed Jun 6 19:49:22 trying reconnect to localhost:10002
Wed Jun 6 19:49:22 reconnect localhost:10002 ok
reconnected to server after rs command (which is normal)
PRIMARY>
Wed Jun 6 19:49:49 Socket recv() errno:104 Connection reset by peer 127.0.0.1:10002
Wed Jun 6 19:49:49 SocketException: remote: 127.0.0.1:10002 error: 9001 socket exception [1] server [127.0.0.1:10002]
Wed Jun 6 19:49:49 DBClientCursor::init call() failed
>
Wed Jun 6 19:49:50 trying reconnect to localhost:10002
Wed Jun 6 19:49:50 reconnect localhost:10002 ok
SECONDARY>
SECONDARY>
SECONDARY>
복원 서버 규칙 나)번이 성립되지 않는 경우를 고려해 보자. 이러한 경우는 [그림 5-7]과 같이 Master가 장애가 발생하여 새로운 마스터가 선출된 다음, 바로 장애가 발생한 서버가 복구되어 투표를 통해 다시 마스터로 선출되는 경우이다. 장애가 발생한 마스터가 다시 마스터로 선출되는 경우는 마스터 선출 규칙에 의해 서버가 가지고 있는 최신의 optime이 10초 이내에 있는 경우이다. 따라서, 마스터 장애 이후 10초 안에 복구되어 다시 투표에서 마스터로 선출된 것이다.
[그림 5-7] 복제 독립 서버의 장애 서버 복원 – 이전 Master로 복원
[그림 5-7]과 같이 장애 발생한 마스터가 복구 후에 다시 마스터로 선출되는 경우에 발생하는 문제점은 [그림 5-8]과 같은 데이터 롤백Rollback 현상이다. [그림 5-8]의 좌측과 같이 슬레이브가 마스터보다 더 많은 데이터를 가지고 있음에도 불구하고, MongoDB는 마스터의 데이터를 기준으로 슬레이브의 데이터를 삭제 처리한다. 이와 같은 현상은 접속 량이 폭주하여 동시에 수많은 데이터를 저장하는 연산이 지속적으로 발생되는 상태에서, 마스터 서버의 장애가 발생하고 슬레이브 중 하나가 마스터로 전환된 다음에 데이터를 입력 받아 저장한다. 그리고 10초 안에 장애가 발생한 이전 마스터가 복구되어 투표를 통해 다시 마스터 권한을 획득하였다면, [그림 5-8]과 같은 현상이 나타난다.
[그림 5-8] 복제 동기화 – Rollback
단일 복제 서버 구조에서는 프로그래머가 수동으로 마스터를 찾아 데이터를 저장하여야 하기 때문에, 데이터 저장 로직으로 인한 데이터 롤백rollback 현상이 거의 발생하지 않는다. 그러나 샤드 서버 구조에서는 mongos가 mongod에 접근할 수 있는 라우터 역할을 담당하고 있기 때문에, 자동으로 마스터를 인식하여 중단없는 데이터 삽입이 가능하도록 만들 수 있다. 이러한 경우에, 장애가 발생한 마스터를 다시 재 기동하는 문제는 데이터 일관성을 고려하여 관리자가 적절하게 판단하여 기동 시간을 조정하여야 한다.
이전 글 : 복제 독립 서버
다음 글 : 복제 독립 서버와 아비타
