Oplog vs Journaling
Basic
몽고디비는 Oplog와 Journaling을 통해서 logging을 한다.
Oplog
Oplog는 replica set에 데이터 변환을 알려주는 열할, journal은 데이터 복구를 위해서 사용한다!고 일단 먼저 정리를 하자.
Oplog는 복구에서도 사용되지만, 내가 볼때에는 이 역할을 복구에도 적용할수 있어서 사용하는 것처럼 보인다. 왜냐하면 데이터를 복구하는 것도 어느 시점 (예, checkpoint)에서 데이터의 변환을 자신의 DB에 적용하는것으로도 볼수 있기 때문이다.
우선 Oplog와 journaling을 비교를 통해 살펴보자 (이것이 풀어서 쓰는것 보다 가장 잘 이해할수 있는 방법이라고 생각한다). 나도 햇갈렸다.
Oplog는 Operation log의 준말로 사용되는 용어이다. capped collection으로 모든 변경되는 로그를 기록하는 로그이다. capped collection은 고정된 사이즈의 collection으로 일종의 circular queue같은 것으로 이해하면 이해하기 쉬울 것이다. 고정 사이즈로 운용이 되다보니 옛날의 데이터를 덮어 쓰는 것이 필요할 것이다. MongoDB에서 직접 관리를 하고 oplog.rs라는 collection으로 기록된다. oplog를 replica set에 전달을 하게되면 secondary node들은oplog을 보고 데이터의 변환을 반영한다. 이것이 가장 큰 기능이고, 다른 용도는 복구 하는 것에도 사용된다.
복구 무엇이냐... 쉽게 말하면 지금 데이터베이스에서 서비스가 진행중인데 갑자기 컴퓨터가 죽거나 맛이가거나 멈추거나 하는 모든 문제 상황에서 데이터베이스가 살아나도록 해주는 것이다. 이 과정은 RDBMS에서 말하는 어느 시점으로 돌리는 것 (rollback)을 포함하는 개념으로 혼용이 되는데, MongoDB는 rollback을 다른 방식으로 사용하고 있기 때문에 이것을 구분지어 사용해야 할것이다.
아무튼, Oplog는 high-level의 operations의 변경된 내용을 저장한다! 간단히 정리할 수 있다. 중요한 사실 한가지는 local database 에 기록되는 내용은 Oplog에 반영되지 않는 것이다.
reference를 읽다보면 local database라는 명칭이 나오는데 설명이 안되어 있어 오해의 소지가 있을것으로 보인다. 나도 그랬다. MongoDB 서버 자신을 위한 컬랙션(local database)를 생성해서 저장한다. local이라는 이름의 database이다. local이라는 것이 다양하게 사용되는데 여기에서는 이름으로 사용된다. 혼동하지 말자.
멱등성(Idempotent)
Journaling
Journaling의 journal은 file system에서도 사용되는 용어인데, file system에서도 디스크나 파일의 변화의 기록들을 가지고 있는 log처럼 사용된다고 본다면, MongoDB에서도 이와 비슷한 개념으로 이해할수 있겠다. 이 journal은 storage engine에 따라서 바뀔수 있지만, 개념상 RDBMS의 WAL과 같다.다. 이 journal은 storage engine에서 복구를 위한 용도이며 자세한 내용은 Wired Tiger에서 상세히 다루고자 한다.
Last updated