[MongoDB] Replica Set

✅ Replica Set Members

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

✅ Replica Set Election(Fail-Over)

Replica Set으로 자동 Fail-Over가 가능하기 때문에 멈춤 없이 서비스를 지속적으로 운영할 수 있는 특징이 있다.

하지만 위의 그림처럼 Primary가 죽게 되면 Read에 대한 요청을 처리할 수 없고, 2개의 Secondary만 남으면 읽기에 대한 요청만 가능해지면서 서비스 요구사항에 따라 장애로 분류될 수 있다. Primary와 Secondary 각각은 서로에게 Heartbeat을 날리면서 살아있는지 체크를 수시로 한다. 만약에 Primary에게 Heartbeat를 보냈는데 응답이 없다면 선출 알고리즘을 통해 새롭게 Primary를 선출(New Primary Elected)하게 된다. 

선출 과정에서 다수결로 선출이 되기 때문에 Replica Set 멤버의 수를 결정할 때 최소 3개 이상, 홀수로 맞추라고 하는 권장 사항이 있다. 투표를 할 수 있는 상태는 Primary, Secondary, Arbiter가 있다. Arbiter는 데이터를 가지고 있지 않고, 투표를 참여하기 위한 멤버로 사용된다.

하지만 P-S-S와 P-S-A를 놓고 봤을때 Primary 하나가 죽으면 Secondary가 그를 대체하는데  데이터를 부담할 수 있는 멤버의 수가 왼쪽은 2개 오른쪽은 1개가 된다. 즉 부담을 감당하는 측면에서는 P-S-S가 오른쪽의 P-S-A보다 훨씬 좋은 구조이다. 

✅ Replica Set Oplog

Oplog를 이용해서 Replica Set의 모든 멤버가 동일한 데이터셋을 유지할 수 있게 된다. 쓰기 요청이 Primary에 들어오게 되면 Primary에 적용을 하고 local database에 있는 Oplog 컬렉션에 변경사항을 기록하면 각 Secondary는 비동기적으로 선반영되어 있는 멤버의 Oplog를 복사해오고 변경을 수행하게 된다. 

✅ Summary

• Replica Set은 HA 솔루션이다.
• 데이터를 들고 있는 멤버의 상태는 Primary와 Secondary가 있다.
• Secondary는 선출을 통해 과반수의 투표를 얻어서 Primary가 될 수 있다.
• Arbiter는 데이터를 들고 있지 않고 Primary 선출 투표에만 참여하는 멤버이다.
• Replica Set은 local database의 Oplog Collection을 통해 복제를 수행한다.