[MongoDB] Replica Set (레플리카셋)

Replica Set 구성

Replica Set 구성

Replica Set의 사용 목적이 HA이기 때문에, 각 멤버들이 각 다른 서버에 위치해있어야 목적에 맞게 효과를 볼 수 있다.

 

 

Status	Description
Primary	• Read/Write 요청 모두 처리할 수 있다. • Write를 처리하는 유일한 멤버이다. • Replica Set에 하나만 존재할 수 있다.
Secondary	• Read에 대한 요청만 처리할 수 있다. • 복제를 통해 Primary와 동일한 데이터 셋을 유지한다. • Replica Set에 여러개가 존재할 수 있다.

아무런 설정없이 읽기/쓰기 요청을 하면 기본적으로 Primary가 처리한다. readPreference 옵션을 넣어 요청해야한다.

 

 

Replica Set Election (Fail-Over)

Replica Set Election (Fail-Over)

단순히 서버 1대가 내려가도 나머지 서버 2대가 살아있어서 된다라는 느낌보다는 좀 더 복잡하다.

 

Secondary 멤버가 죽으면 그렇게 해석할 수 있지만, Primary 멤버가 죽으면 문제가 발생할 수 있다.

Primary는 유일하게 Write 요청을 처리할 수 있는 멤버이다. 따라서 Primary가 죽으면 Secondary만 살아있기 때문에 Write 요청을 받을 수 없다. 이는 서비스 요구사항에 따라 장애로 판단할 수 있다.

 

ReplicaSet에서 Primary가 없다고 인지를 하게 되면, 자동으로 Primary를 선출해서 자동 Failover를 진행한다.

내부적으로 각 멤버들은 서로 Heartbeat를 통해 살아있는지 수시로 확인한다. 만약에 Primary에게 Heartbeat 요청을 했는데, 답변이 없으면 선출 알고리즘을 통해 새롭게 Primary를 선출하게 된다.

 

선출에 대한 기준은?

Priority 설정값이나, 복제 지연이 없는지 내부적으로 여러 정보들을 확인해서 Primary가 되려고 하는 Secondary가 과반수의 투표를 얻게 되면 Primary로 승격하게 된다.

그래서 ReplicaSet 멤버 수를 결정할 때 최소 3개 이상, 홀수로 맞추는 것(for 과반수)을 권장하고 있다.

 

투표를 할 수 있는 멤버의 상태가 추가로 하나 더 존재한다. → Arbiter

 

Arbiter

Arbiter은 Primary, Secondary와 다르게 데이터를 들지 않고 있다. Primary 선출에 참여하기 위한 멤버로 구성하고 있다.

이는 비용 문제 때문에 서버를 구매하는 것이 부담될 때 리소스 작은 서버를 하나 이용해서 Primary가 계속 살아있을 수 있다는 것을 보장하기 위해 사용된다.

 

권장되는 방식은 아니다. PSA방식은 Secondary 서버 한대가 죽었을 때 Primary에게 부하를 많이 줄 수 있기 때문이다. (PSS와 다르게)

 

Replica Set Oplog

Operation Log의 약자

 

Replica Set Oplog

Oplog를 이용해서 ReplicaSet의 모든 멤버가 동일한 데이터셋을 유지할 수 있도록 한다.

 

쓰기 요청 → Primary 적용 → local database에 있는 oplog 컬렉션에 변경사항 기록 → 각 Secondary가 비동기적으로 선반영되어있는 멤버의 oplog를 보고 변경을 수행하게 된다.

꼭 Primary 뿐 아니라, Secondary가 자신보다 앞서있는 secondary의 oplog를 보고 복제할 수도 있다.