[MongoDB] - MongoDB Replicaset

개요

MongDB Replicaset 은 모든 데이터를 복제하여 가지고 있는 몽고 데이터베이스 프로세스의(mongod) 그룹임 모든 프로덕션 배포의 기초가 되며 중복을 허용하고 데이터베이스의 가용성을 높입니다.

mongod 는 MongoDB 시스템의 기본 데몬 프로세스입니다. 데이터 요청 처리, 데이터 엑세스 관리, 백그라운드 관리 작업을 수행합니다.

중복성과 가용성

중복성

분산 시스템 환경에서 데이터의 복제본을 여러 서버에 유지하는것은 조회 연산의 overhead를 분산시킬 수 있고, 데이터의 지역성을 높일 수 있음

가용성

각 데이터베이스 서버는 동일한 데이터를 가지고있기 때문에 Primary 서버가 다운될경우에도 이를 교체할 수 있음 => increase fault tolerance

Replication of MongoDB

데이터베이스 세트 중 하나는 Primary node 로 설정하고 선택사항으로 Arbiter node를 설정할 수 있습니다. 모든 쓰기 연산은 Primary node 에하고 Primary node 는 데이터 변경사항을 oplog 에 저장합니다.

 

Arbiter Node

기본적으로 투표를 위해 사용되며 Primary Node를 승격시키기 위한 목적으로만 사용되는 노드이다 데이터의 복제와 읽기 부하를 받지 않으면서 투표에 참여함으로써 레플리카셋의 안정성을 유지하는데 도움을 줍니다.

 

Oplog

Oplog는 MongoDB에서 변경 사항을 기록하는 특수한 컬렉션으로, Replication Set에서 데이터를 복제하는 데 사용됩니다. Oplog는 "operation log"의 약어로, 쓰기 작업(INSERT, UPDATE, DELETE)이 발생할 때마다 해당 작업에 대한 로그를 기록합니다.

Oplog는 다음과 같은 주요 필드를 포함하는 BSON 문서의 컬렉션입니다:

• ts (timestamp): Oplog 항목이 기록된 시간을 나타냅니다.
• h (operation header): 변경 작업의 유형을 식별하는 데 사용됩니다. INSERT, UPDATE, DELETE 등이 여기에 포함됩니다.
• v (version): Oplog의 버전을 나타냅니다.
• op (operation): 수행된 작업의 유형을 나타냅니다.
• ns (namespace): 작업이 수행된 데이터베이스와 컬렉션을 나타냅니다.
• o (object): 실제 변경된 데이터를 포함합니다.

데이터를 복제하기 위해 Secondary 노드는 Primary 노드에서 Oplog를 주기적으로 폴링(Polling)하거나, 이벤트 기반 메커니즘을 사용하여 변경 사항을 실시간으로 받아들일 수 있습니다. 이벤트 기반 메커니즘은 데이터베이스 엔진이 변경 사항이 발생할 때마다 이를 감지하고 Oplog에 기록하는 방식입니다.

데이터 복제 과정

1. Initial Sync:
   • 새로운 Secondary 노드를 Replication Set에 추가할 때, 초기 데이터 동기화를 위해 Primary 노드에서 데이터의 전체 복사본을 Secondary 노드로 전송합니다.
   • 이로써 Secondary 노드는 Primary 노드의 현재 상태를 복제하게 됩니다.
2. Oplog Tail:
   • 초기 동기화 이후, Secondary 노드는 Primary 노드의 Oplog를 주기적으로 확인(tail)하여 변경 사항을 가져옵니다.
   • Oplog는 크기가 제한되어 있으며, 가장 오래된 항목은 지워지므로, Secondary 노드는 자체 Oplog의 마지막 위치를 추적하여 Primary 노드에서 발생한 변경 사항을 실시간으로 따라가게 됩니다.
3. Replication Process:
   • Oplog의 변경 사항을 가져오는 과정은 복제 프로세스를 통해 이루어집니다.
   • Secondary 노드는 주기적으로 Primary 노드의 Oplog를 확인하여 변경된 데이터를 확인합니다.
   • 변경된 데이터는 복제 프로세스를 통해 Secondary 노드의 데이터베이스로 전송되고 적용됩니다.
4. Asynchronous Replication:
   • MongoDB Replication은 비동기식(Asynchronous)으로 동작합니다. 즉, Primary 노드에서 변경 사항이 일어나면 이를 즉시 Secondary 노드로 전송하지 않고, Oplog에 기록한 뒤 주기적으로 전송합니다.
   • 이로써 Primary 노드와 Secondary 노드 간의 네트워크 지연이나 다른 이슈로 인해 Secondary 노드가 일시적으로 동기화되지 않더라도 전체 시스템이 영향을 받지 않습니다.

리플리카셋 투표

Primary 노드가 불능일 election 이벤트가 발생하고 Secondary node 중 하나가 투표를 통해 Primary 노드로 승격합니다.

투표 발생 이벤트

• 리플리카셋에 새로운 노드를 추가할때
• 리플리카셋을 초기화 할때
• replicaset의 구성을 바꿀 때
  • rs.stepDown() or rs.reconfig()
• 세컨더리가 프라이머리 노드로 부터 응답을 timeout 이상 받지 못했을 때

투표에 영향을 주는 것들

• Replication Election Protocol
  • Replication protocolVersion: 1은 복제본 세트의 장애 조치 시간을 단축하고 여러 개의 동시 프라이머리를 빠르게 감지합니다.
• Heartbeats
  • 레플리카 셋안에 존재하는 각 노드들은 서로 Heartbeat 를 보내는데 만약 상대노드에서 신호를 받지 못하면 해당 노드를 사용 불가로 판단합니다.
• Member priority
  • 기본적으로 우선순위가 높은 세컨더리노드가 승격될 확률이 높지만 우선순위가 낮은 세컨더리가 프라이머리로 잠시동안 승격 할 수도있습니다. 리플리카 셋 멤버들은 우선순위가 높은 노드가 Primary 가 될 수 있도록 이러한 투표과정을 반복합니다.
• Mirrored Reads
• Loss of Data center
  • 데이터 센터가 손상될 경우 데이터 센터의 나머지 노드들이 Primary 노드를 선출하는데 영향을 미칠 수 있습니다 (가능하면 물리적으로 다른 데이터 센터에 배치하여 세트 구성원 중하나가 기본 구성원이 될 수 있는 가능성을 최대화 해야합니다)

참고

https://www.mongodb.com/docs/manual/replication/

https://www.mongodb.com/docs/manual/core/replica-set-elections/#std-label-replica-set-elections