MongoDB Replica Set

MongoDB 의 3가지 형태 중 하나인

Replica set 에 대해 알아보겠다.

 

특징

- High Availability (고 가용성)

- 가장 많이 사용됨

- 무중단 서비스를 가능하도록 만들어주는 최소 단위

 

 

Replica set 의 맴버

현재 위 그림에서 MongoDB 는 3개의 맴버를 가지고 있다. (Primary, Secondary, Secondary)

각 맴버는 각각 다른 서버에 존재한다. (모두 하나의 서버에 존재 할 수 도 있다.)

 

맴버의 상태로는 3가지가 있다.

Primary

- Read/Write 요청 모두 처리 가능하다.

- Write 를 처리 할 수 있는 유일한 맴버이다.

- Replica set 에서 하나만 존재

 

Secondary

- Read에 대한 요청만 처리할 수 있다.

- 복제를 통해 Primary와 동일한 데이터 셋을 유지한다.

- Replica set에 여러개가 존재 할 수 있다.

 

Arbiter (그림에는 없음)

- Primary 를 선출할 때 투표를 행사하는 용도의 맴버

- Secondary에서 데이터를 저장하는 기능을 뺀 것이라 생각하자.

 

그림 설명을 이어 나가자면..

Write 요청은 Primary 맴버로 하는 것을 볼 수 있고

Read 요청은 Secondary 맴버로 하는 것을 볼 수 있다.

하지만, Read 요청에 대한 기본 설정은 Primary 로 하는 것이고

Read Preference 설정을 해주어야만 Secondary 가 수행한다.

기본 설정 대로라면.. Secondary는 fail-over 용도로만 사용된다.

 

 

Replica Set 의 Automatic Fail-Over

그림과 같이 Replica set 은 각 맴버들 간 Heartbeat 라는 신호를 서로에게 날리며

health check 를 수행한다.

 

그림과 같이 health check 를 하다가 갑자기 Primary 가 장애가 일어난다면...

Write 요청을 처리하는 맴버가 없어진 것이기 때문에

Secondary 하나를 Primary 로 선출한다. (Fail-Over)

 

 

Replica Set 의 Oplog

Replica set 은 oplog 라는 것을 통해서

Replica Set 의 모든 맴버가 동일한 데이터 셋을 가지도록 유지 시켜준다.

 

oplog 동작 과정은 다음과 같다.

1. Primary write 연산 수행

2. Primary local 의 oplog 에 변경사항 기록

3. Secondary는 Primary의 oplog 변경사항을 읽어서 자신 데이터 셋에 반영시킴(비동기)

 

<참고>

oplog 는 Primary 에만 존재하는 것이 아니라 Secondary에도 존재한다.

Secondary 끼리도 데이터셋 정합을 맞춘다는 것이다.