MongoDB는 HA(High Availability)를 위해 클러스터를 구축하는 개념이 Replica Set이다.

이 클러스터를 구축하기 위해서 각각의 데이터베이스 서버들은 Primary, Secondary, Arbiter라는 역할을 가질 수 있으며 P-S-S, P-S-A 구조를 통해 레플리카셋을 구축할 수 있다.

Secondary는 Primary가 문제가 생겼을 때를 위해 존재하는 대타이다.

그렇기 때문에 데이터 변경을 처리할 수 있는 유일한 멤버는 Primary이며, Primary는 변경사항을 Oplog에 기록하여 나머지 멤버들이 Primary 와 동기화를 비동기적으로 진행할 수 있도록 하는 것이다.

Oplog

Oplog는 capped collection 이라는 특수한 컬렉션에 저장된다.

마스터 노드에 요청되는 연산들이 로그로 기록되는 파일
capped collection은 고정된 크기를 가지며 해당 크기가 꽉차면 오래된 순으로 자동 삭제가 되는 로그성 데이터를 저장하기 편한 컬렉션이다.
- local이라는 이름의 db 내 oplog.rs 이라는 이름 컬렉션에 저장된다.
- local 디비에 기록된 내용은 oplog에는 반영되지 않는다.
Mongodb 4.0부터는 용량 초과해도 처리 안된 건들은 삭제 되지 않도록 할 수 있다.

oplog는 os에 따라 기본적으로 할당되는 사이즈가 다르며 사이즈를 변경할 수 있다.

Journaling

실패시 복구상황에서 사용되는 journal 파일에 로깅하는 행위를 말한다.

복구를 하는 가장 일반적이고 보편화된 방법은 checkpoint를 위한 snapshot을 만들고, 그 후에 log를 통해서 복구하는 방법이다. 이 log를 MongoDB에서는 journal이라고 부른다.

MongoDB의 StorageEngine인 WiredTiger는 쓰기 작업이 발생할 때마다 하나의 journal record를 생성하며 journal에는 해당 쿼리와 인덱스 변경에 대한 내용이 포함되어 있다.

이 파일은 config에서 설정한 data경로의 journal 폴더에 작성되며 write-ahead log 이므로 core data에 반영되기 전에 먼저 로깅된다.

WiredTiger의 journal은 checkpoint사이의 모든 데이터 작업 사항을 유지한다.

checkpoint는 journal과 데이터 파일이 동기화되는 시점을 말한다. 3.6버전부터 60초 간격으로 check point가 생성된다. 주기적으로 동작하기 때문에 새로운 check point가 생성되며 그 이전 journal은 삭제되거나 덮어쓰며 관리를 함.

그래서 재해상황(hard shutdown)시에 journal 파일을 사용하여 마지막 체크포인트 이후 모든 변경사항을 재실행하여 영속성을 보장한다.

WiredTiger는 MVCC (MultiVersion Concurrency Control)을 사용하여 많은 이점을 가져가고있다.