리플리카셋의 개념과 동작 원리
리플리카셋 - ReplicaSet
- primary 서버 : 리플리카에서 첫 번째 입력을 담당하는 서버
- secondary 서버 : primary 서버를 제외한 나머지 서버
- primary 서버에 문제가 생기게 되면 자동으로 secondary 서버에서 데이터 입출력을 담당
리플리카셋의 주요 특징
- 프라이머리 서버는 세컨더리 서버를 2초단위로 상태 체크하여 데이터 동기화를 위한 HeartBeat 확인
- HeartBeat 수신 결과, 세컨더리 서버를 사용할 수 없는 상황이 되더라도 데이터 복제만 중단될 뿐,
프라이머리 서버는 데이터 수신/저장을 계속 담당
- 세컨더리 서버가 복구되면 그간의 밀린 데이터를 복구하기 위해 프라이머리 서버는 Oplog를 저장하는데,
이후 세컨더리 서버 복구 시, 자동 동기화
- 프라이머리 서버가 장애 상황이 된다면, 세컨더리 서버를 프라이머리 서버로 만듦
- 리플리카셋(복제 집합)은 한 개의 primary와 두 개의 secondary로 구성
- 복제 집합으로 구성된 각각의 노드는 자신을 제외한 다른 노드들이 죽었는지 살았는지를 HeartBeat를 이용해 주기적으로 점검
- 몽고디비의 HeartBeat는 2초 단위로 수행되며, HeartBeat를 받은 서버는 자신의 상태 코드를 HeartBeat를 요청한 서버에게 보내줌
- 프라이머리 서버의 HeartBeat는 항상 복제 집합을 구성하고 있는 노드의 개수의 과반수만큼을 유지해야 함
- 만약 프라이머리 서버가 과반수의 HeartBeat를 가지고 있지 않는다면,
해당 서버는 세컨더리 서버로 전환되고 전체 복제 집합은 프라이머리 서버 부재에 따른 투표를 시행
- 프라이머리가 될 수 있는 자격 조건으로는 priority(마스터가 될 수 있는 우선순위),
votes(자신을 포함한 복제 집합의 노드 개수의 과반수 투표) 등
MongoDB 복제 시스템의 한계
- 한 복제 집합을 구성할 수 있는 노드의 최대 개수는 12개
- 한 복제 집합에서 투표를 할 수 있는 노드의 최대 개수는 7개
- 슬레이브가 아무리 빨리 데이터를 동기화한다고 해도,
마스터와의 통신 지연 시칸만큼의 차이를 가질 수 있음
- 부하를 견디지 못해 마스터 서버가 죽어버렸을 경우,
Oplog에 동기화 되지 않은 채 남아있는 데이터 연산을 잃어버리는 현상이 발생할 수 있음
- 저널링 파일에 데이터를 저장하는 방법의 경우에도 group commits 주기 (100ms) 안에 데이터가 존재하는데도
시스템이 다운되어 메모리에 저장된 데이터가 날아갔을 경우 복구 불가능
리플리카셋 구성
프라이머리 서버 실행
mongod --replSet downSet --dbpath c:\data --port 20000
첫 번째 세컨더리 서버 사용 폴더 생성
mkdir c:\data2
첫 번째 세컨더리 서버 실행
mongod --replSet downSet --dbpath c:\data2 --port 20001
두 번째 세컨더리 서버 사용 폴더 생성
mkdir c:\data3
두 번째 세컨더리 서버 실행
mongod --replSet downSet --dbpath c:\data3 --port 20002
프라이머리 서버 접속 / config 생성
mongo --port 20000
var config =
{
_id:'downSet',
members:
[
{_id:0,
host:'localhost:20000'
},
{_id:1,
host:'localhost:20001'
},
{_id:2,
host:'localhost:20002'
}
]
}
rs.initiate(config);
- 20000 - Primary
20001, 20002 - Secondary
20000 shutdown 시 , 자동적으로 20001 / 20002 중 한 서버가 Primary로 승계됨
장애 발생 시 대응
리플리카셋 초기 세팅
프라이머리 서버 장애 발생
새로운 프라이머리 서버 채택
