복제 세트는 oplog와 heartbeat라는 두가지 메커니즘을 사용한다.

• oplog를 통해 데이터 복제가 가능하고
• 하트비트를 통해 몽고DB 노드 간 헬스체크를 한다.

오피로그

oplog는 캡드(capped) 컬렉션으로 되어있으며 데이터에 대한 모든 수정사항을 기록한다. (해당 oplog 컬렉션은 local 데이터베이스에 존재한다.)

• 프라이머리 노드에서 쓰기 연산이 발생할 때마다 oplog에 변경사항 데이터를 추가한다
• 해당 oplog는 세컨더리 노드에서 replay 되어 데이터 복제가 이루어진다.
• oplog에는 타임스템프도 포함되는데, 이 타임스템프를 사용하여 변경할 최신 항목을 추적한다. (즉, 어디까지 복제되었는지 판단하는데 사용됨)

여러 도큐먼트에 연산은 개별적으로 기록된다. 가령, multi: true 와 같은 대량 연산의 경우 영향 받는 각 도큐먼트에 대한 oplog가 개별적으로 생성된다.

프라이머리의 변경사항이 복제 노드에 전파되는 과정

프라이머리에 쓰기 작업이 수행될 경우 다음과 같은 순서를 거친다.

1. 쓰기가 기록되고 프라이머리 노드의 oplog에 변경사항이 추가된다.
2. 세컨더리 노드는 oplog에서 자신이 수행했던 타임스템프 이후의 변경사항을 질의한다.
3. 만약 이후 변경사항이 있을 경우, oplog에서 조회된 변경사항에 대해 replay를 수행한 뒤 자신의 oplog에도 추가한다.

복제 중지

오피로그는 캡드 컬렉션이다. 만약, 세컨더리 노드가 오랜시간 오프라인 상태였을 경우, 프라이머리 노드의 oplog에 오래된 변경 사항은 이미 지워졌을수도 있다. 이럴 경우 복제는 더이상 할 수 없는 상태가 된다.

• 세컨더리 노드가 프라이머리 노드의 oplog로부터 동기화할 지점을 찾지 못하면, 세컨더리 노드는 프라이머리 노드에 대해 완벽한 복제본임을 신뢰할 수 없게 된다.

repl: replication data too stale. halting

이런 경우, 해결책은.. 프라이머리 데이터를 처음부터 다시 재동기화하는 방법 뿐이다.

• 그래서 세컨더리 노드에서 복제 지연이 발생하는 것을 모니터링 해야하며