MongoDB Oplog 크기 변경하기

MongoDB 복제 구성에서 Primary로부터 발생한 변경사항을 다른 Secondary 멤버에 복제하기 위해 Oplog라는 Capped Collection을 사용한다. Capped Collection은 크기가 제한 된 Collection이다. 예를 들어 10GB의 Capped Collection을 생성하면 10GB를 넘어서는 순간 가장 오래된 데이터를 삭제하는 FIFO 구조의 Collection이다.

 

 

MongoDB의 상태가 정상일 때는 oplog를 통해 금방 복제를 따라간다. 그래서 Oplog의 Capped 크기가 상관없을 것 같지만, 운영 환경에서 의외로 여러가지 이유에 의해 크기를 조절해줘야한다. 몇 가지 예를 들어보면

• 서버 점검이 오래 걸려서 다시 정상으로 돌아왔을 때, initial sync가 아닌 일반 복제로 따라가기 위해 oplog 크기를 늘려준다.
• 파일 복사 형태의 백업 정책을 갖고 있어서 백업하는 동안 Fsync Lock을 걸어주는데, 백업 시간이 오래걸려서 마찬가지로 oplog 크기를 늘려준다.
• 매일 정기적으로 배치 형태의 트래픽이 발생해서 Oplog Window Hour가 0에 수렴하는 경우
• 일반 데이터를 저장할 공간이 필요해서 Oplog 크기를 줄이는 경우

 

 

rs_1 [direct: secondary] test> rs.printReplicationInfo()
actual oplog size
'10000 MB'
---
configured oplog size
'10000 MB'
---
log length start to end
'6943753 secs (1928.82 hrs)'
---
oplog first event time
'Fri Feb 17 2023 11:23:12 GMT+0900 (__REGIEON__ Standard Time)'
---
oplog last event time
'Mon May 08 2023 20:12:25 GMT+0900 (__REGIEON__ Standard Time)'
---
now
'Mon May 08 2023 20:12:33 GMT+0900 (__REGIEON__ Standard Time)'

등 여러 가지 운영요소들이 있다. Oplog Window Hour는 oplog의 가장 처음과 마지막 변경사항에 대한 시간 차이를 의미한다. 대략적으로 얼마나 복제가 지연되어도 oplog를 통해 따라갈 수 있는지 확인할 수 있는 수치이다.

 

 

그래서 발생하는 DML 트래픽에 따라 위와 같이 오르고 내리고하는 것을 볼 수 있다. 눌림목이 있는 부분은 트래픽이 평소보다 많은 경우를 의미한다. 여하튼, 운영하는 관점에서 Oplog 변경에 대한 주의사항도 알고 있어야한다.

 

 

Oplog 수정

Distribution : 3 Member Replica set
Version : MongoDB 5.0.13

Oplog 설정은 mongod 프로세스를 최초에 올릴 때, 옵션 혹은 config file로 설정할 수 있다. 만약 기존에 oplog size 설정이 안되어 있었다면 MongoDB에서 자동으로 몇 가지 계산을 통해 설정한다. Oplog는 Online 상태에서 명령으로 변경이 가능하다. 혼동이 올 수 있는 부분은 oplog가 한번 설정되고 나서 config file이나 옵션을 수정하고 재기동해도 변경되지 않는다. 이게 헷갈려서 oplog 수정하면 기동 옵션이나 config file도 함께 수정하는 것을 권장한다.

 

 

Oplog 늘리기

줄이는데는 Primary와 Secondary 순서가 중요한다. 늘리는경우, 순서나 병렬 작업 등 상관없다.

rs_1 [direct: secondary] test> use local
switched to db local
rs_1 [direct: secondary] local> db.oplog.rs.stats().maxSize
2097152000

먼저 설정된 Oplog Size를 확인한다. 2GB로 설정되어 있는 것을 볼 수 있다.

 

 

[root@__HOST__:/root/mongodb/data]$ du -sh *
340K    admin
348K    config
200M    diagnostic.data
300M    journal
188M    local
...
...

 

local database의 물리적은 크기도 확인해서 일정 수치 이후로 증가하지 않고 삭제하는 것을 확인해보자.

 

 

function makeTxt(length) {
    let result = '';
    const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    const charactersLength = characters.length;
    let counter = 0;
    while (counter < length) {
      result += characters.charAt(Math.floor(Math.random() * charactersLength));
      counter += 1;
    }
    return result;
}

for(var i=0; i<10; i++){
	var arr = [];
    for(var j=0; j<10000; j++){
    	arr.push({a: j, txt: makeTxt(100)})
    };
    db.test.insertMany(arr);
};

위와 같이 변경사항이 여럿 발생하도록 실행해보자. 최대 크기까지 도달하도록 수정할 예정이다. MongoDB는 데이터를 압축하기 때문에 물리적인 크기가 Oplog의 최대치까지 올라가지 않는다. 즉, Oplog의 설정 크기는 압축하기 이전인 데이터에 대한 크기이다. oplog를 다 사용했는지는 collection의 세부 정보와 복제정보를 통해 확인할 수 있다.

 

 

rs_1 [direct: primary] local> rs.printReplicationInfo()
actual oplog size
'2000 MB'
---
configured oplog size
'2000 MB'
---
log length start to end
'463.9999930858612 secs (0.13 hrs)'
---
oplog first event time
'Mon May 08 2023 20:52:21 GMT+0900 (__REGIEON__ Standard Time)'
---
oplog last event time
'Mon May 08 2023 21:00:05 GMT+0900 (__REGIEON__ Standard Time)'
---
now
'Mon May 08 2023 21:00:05 GMT+0900 (__REGIEON__ Standard Time)'

rs_1 [direct: primary] local> db.oplog.rs.stats().maxSize
2097152000
rs_1 [direct: primary] local> db.oplog.rs.stats().size
2091786256

물리적인 크기도 확인하면 어느순간부터 늘어나지 않는 것을 확인할 수 있다. oplog collection에 대한 Stat을 확인해보면 최대크기까지 사용한 것을 볼 수 있고 Oplog Window Hour도 크게 줄어든 것을 확인할 수 있다. 더 담을 수 있도록 수치를 늘려보겠다.

 

 

rs_1 [direct: primary] test> db.adminCommand({replSetResizeOplog: 1, size: Double(3000)})
{
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1683547464, i: 2 }),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1683547464, i: 2 })
}

rs_1 [direct: primary] local> db.oplog.rs.stats().maxSize
Long("3145728000")
rs_1 [direct: primary] local> db.oplog.rs.stats().size
2091791838

MB 단위로 값을 넣어서 실행할 수 있고 변경 이후에도 maxSize가 늘어난 것을 확인했다.

 

 

Oplog 줄이기

Oplog를 줄일 때는 순서가 중요하다. Secondary 먼저 줄여주고 이후 Primary를 줄여줘야한다. 크기만 변경하면 순서도 상관없지만, 줄인 후 아무런 변경이 없으면 데이터 파일의 크기가 그대로 남아 해당 공간을 사용하지 못한다. 그래서 compaction까지 수행해주기 위해 secondary에서 먼저 실행하고 stepdown 후, 나머지 멤버도 변경해준다.

1. Secondary 먼저 oplog 줄인다.
2. Secondary에서 compaction 명령 수행한다.
3. Primary Stepdown
4. Stepdown한  Primary도 oplog를 줄인다.
5. 다시 compaction

 

 

[root@__HOST__:/root/mongodb/data]$ du -sh local
449M    local

현재 물리적인 크기를 확인하고 Secondary부터 Oplog 크기를 변경해준다.

 

 

# Secondary 수행
rs_1 [direct: secondary] test> db.adminCommand({replSetResizeOplog: 1, size: Double(990)})
rs_1 [direct: secondary] test> use local
rs_1 [direct: secondary] local> db.runCommand({ "compact" : "oplog.rs" } )

# Primary 수행
rs_1 [direct: primary] test> rs.stepDown()
rs_1 [direct: secondary] test> db.adminCommand({replSetResizeOplog: 1, size: Double(990)})

작업은 간단하다. Primary에서도 Compaction 명령을 수행하기 전에 물리적인 크기를 확인하자. 위와 동일하게 물리적인 크기는 줄어들지 않은 것을 확인할 수 있다.

 

 

 

rs_1 [direct: secondary] test> use local
rs_1 [direct: secondary] local> db.runCommand({ "compact" : "oplog.rs" } )

### 물리적 크기 확인
[root@__HOST__:/root/mongodb/data]$ du -sh local
268M    local

compact 명령을 수행하고 나서야 물리적 데이터 파일 크기가 줄어든 것을 확인할 수 있었다. compaction은 선택적이지만, 데이터를 더 저장할 수 있도록 용량확보를 미리 해놓는 것이 좋다. 꼭 함께 수행해주는 것을 권장한다.