MongoDB의 데베지움 커넥터를 사용하기 위해서는 MongoDB 클러스터를 구축하고 oplog를 분석해서 데이터를 캡쳐해야한다.
oplog는 MySQL의 binlog, PostgreSQL의 WAL 과 비슷하다고 보면 된다. 대표적으로 binlog와 oplog를 비교하면 아래와 같은 차이가 있다.
oplog vs. binlog
| 사용 데이터베이스 | MongoDB (NoSQL) | MySQL, MariaDB (SQL) |
| 주요 목적 | 데이터 복제, 변경 사항 스트리밍 | 데이터 복제, 복구, 감사 |
| 기록 형태 | 순차적 로그 (텍스트 기반) | 바이너리 로그 |
| 적용 사례 | 데이터베이스 클러스터 내 고가용성 유지 | 데이터 복제, 포인트-인-타임 복구, 변경 사항 감사 |
| 데이터 변경 사항 기록 | 삽입, 갱신, 삭제 | DDL 및 DML 쿼리 |
| 효율성 | 데이터 변경 사항의 간단한 기록으로 빠른 동기화 가능 | 바이너리 형태로 기록하여 복제 효율성 증가 |
대부분 바이너리 로그로 되어있는 기록형태를 감안했을 때, oplog는 희한하게 텍스트기반 스키마로 작성되어있다.
oplog를 mongoDB클러스터의 local 에서 db.oplog.rs.find().pretty() 명령어를 통해 뜯어보면 다음과 같다.
oplog에서는 정의되어있는 스키마마다 다음과 같은 정보를 담고있다.
| ts | Timestamp | 오퍼레이션을 기록한 시간의 타임스탬프입니다. 이는 oplog 항목의 순서를 결정하는 데 사용됩니다. |
| h | Long | 오퍼레이션의 해시 값입니다. 각 오퍼레이션이 고유함을 보장합니다. |
| op | String | 오퍼레이션의 타입을 나타냅니다. 예를 들어, 'i'는 삽입(insert), 'u'는 업데이트(update), 'd'는 삭제(delete)를 의미합니다. |
| ns | String | 오퍼레이션이 발생한 데이터베이스와 컬렉션의 이름입니다. 예: "mydatabase.mycollection" |
| o | Document | 오퍼레이션의 세부 사항을 담고 있습니다. 삽입의 경우 삽입된 문서, 업데이트의 경우 업데이트 사항 등입니다. |
| o2 | Document | 업데이트 오퍼레이션의 경우, 업데이트되는 문서의 _id를 포함합니다. 삭제나 삽입 오퍼레이션에는 사용되지 않습니다. |
스키마가 모두 텍스트기반이라서 바이너리 로그보다 비효율적일것 같다고 생각했는데 MongoDB내부엔진 WiredTiger이 알아서 잘 처리해준다고 한다..
몽고디비 레플리카셋
oplog가 Standalone/local 모드에서는 기록되지 않는것과는 별개로, 서비스 운영에 있어서 레플리카 셋 구축은 필수이다.
PSS: 서로 헬스체크를 해주고 Primary노드에 장애 및 오류가 발생했을 때 신속하게 복구 할 수 있도록 한다. 이로써, 높은 가용성(HA)을 보장한다.
PSA: Arbiter노드는 서버의 리소스를 많이 담고 있지 않고, 실제로도 데이터를 담고 있지 않기 때문에 안정성이 낮다.
도커이미지를 띄우고 아무 mongosh들어가서 인스턴스를 초기화 시켜주었다.
본격적인 클러스터 구축 및 데베지움 연동은 part2에서 이어서..