Docs Menu
Docs Home
/
MongoDB 매뉴얼
/
복제

복제본 세트 Oplog

이 페이지의 내용

  • Oplog 크기
  • 더 큰 Oplog 크기가 필요할 수 있는 워크로드
  • Oplog Status
  • 저속 oplog 애플리케이션
  • Oplog 컬렉션 동작

oplog (작업 로그)는 데이터베이스에 저장된 데이터를 수정하는 모든 작업의 롤링 기록을 유지하는 특수 고정 사이즈 컬렉션 입니다. 쓰기 작업이 데이터를 수정하지 않거나 실패하면 oplog 항목이 생성되지 않습니다.

다른 제한이 있는 컬렉션과 달리, oplog는 majority commit point삭제를 방지하기 위해 구성된 크기 제한을 초과하여 커질 수 있습니다.

MongoDB는 프라이머리에 데이터베이스 연산을 적용한 후 프라이머리의 oplog에 연산을 기록합니다. 그러면 세컨더리 노드가 비동기 프로세스로 이러한 연산을 복사하고 적용합니다. 모든 복제본 세트 노드는 local.oplog.rs collection에 oplog의 사본을 포함하고 있으며 이를 통해 데이터베이스의 현재 상태를 유지할 수 있습니다.

복제를 촉진하기 위해 모든 복제본 세트 구성원은 다른 모든 구성원에게 하트비트(핑)를 보냅니다. 모든 보조 멤버는 다른 멤버로부터 oplog 항목을 가져올 수 있습니다.

oplog의 각 작업은 멱등을 갖습니다. 즉, oplog 작업은 대상 데이터세트에 한 번 적용하든 여러 번 적용하든 동일한 결과를 생성합니다.

Oplog 크기

복제본 세트 멤버를 처음 시작할 때 oplog 크기를 지정하지 않으면 MongoDB가 기본 크기의 oplog를 만듭니다.

Unix 및 Windows 시스템의 경우

기본 oplog 크기는 스토리지 엔진에 따라 다릅니다:

스토리지 엔진
기본 oplog 크기
디스크 여유 공간의 5%
물리적 메모리의 5%

기본 oplog 크기에는 다음과 같은 제약 조건이 있습니다.

  • 최소 oplog 크기는 990MB입니다. 사용 가능한 디스크 공간 또는 물리적 메모리의 5%(스토리지 엔진에 따라 해당하는 값)가 990GB보다 작은 경우 기본 oplog 크기는 990GB입니다.

  • 최대 기본 oplog 크기는 50GB입니다. 사용 가능한 디스크 공간 또는 물리적 메모리의 5%(스토리지 엔진에 따라 해당하는 값)가 50GB보다 큰 경우 기본 oplog 크기는 50GB입니다.

64비트 macOS 시스템의 경우

스토리지 엔진에 따라 사용 가능한 디스크 공간 또는 실제 메모리의 기본 oplog 크기는 192 MB입니다.

스토리지 엔진
기본 oplog 크기
192MB의 디스크 여유 공간
192MB의 물리적 메모리

대부분의 경우 기본 oplog 크기로 충분합니다. 예를 들어, oplog가 디스크 여유 공간의 5%이고 24시간 동안의 작업으로 가득 차면 세컨더리는 복제를 계속할 수 없을 정도로 오래 되지 않고 최대 24시간 동안 oplog의 항목 복사를 중지할 수 있습니다. 그러나 대부분의 복제본 세트는 작업 볼륨이 훨씬 낮으며 해당 oplog는 훨씬 더 많은 수의 작업을 보유할 수 있습니다.

mongod 가 oplog를 생성하기 전에는oplogSizeMB 옵션을 사용하여 크기를 지정할 수 있습니다. 복제본 세트 노드를 처음 시작한 후에는 replSetResizeOplog 관리 명령을 사용하여 oplog 크기를 변경할 수 있습니다. replSetResizeOplog을 사용하면 mongod 프로세스를 다시 시작하지 않고도 oplog의 크기를 동적으로 조정할 수 있습니다.

최소 Oplog 보존 기간

다음 기준이 모두 충족되는 경우에만 mongod에서 oplog 항목을 제거하는 최소 시간 수를 지정하여 oplog 항목을 보존할 수 있습니다.

  • oplog가 구성된 최대 크기에 도달했습니다.

  • oplog 항목이 호스트 시스템 시계를 기준으로 구성된 시간보다 오래된 경우

기본적으로 MongoDB는 최소 oplog 보존 기간을 설정하지 않으며, 설정된 최대 oplog 크기를 유지하기 위해 가장 오래된 항목부터 자동으로 oplog를 잘라냅니다.

mongod 시작 시 최소 oplog 보존 기간을 구성하려면 다음 중 하나를 수행하십시오.

실행 중인 mongod 의 최소 oplog 보존 기간을 구성하려면 replSetResizeOplog 를 사용하십시오. mongod 실행 시 최소 oplog 보존 기간을 설정하면 시작 시 설정된 모든 값이 재정의됩니다. 서버를 다시 시작해도 변경 사항을 유지하려면 해당 구성 파일 설정 또는 명령줄 옵션의 값을 업데이트해야 합니다.

Oplog 윈도우 (oplog window)

oplog 항목에는 타임스탬프가 기록되어 있습니다. oplog 윈도우(oplog window)는 oplog에서 가장 최근의 타임스탬프와 가장 오래된 타임스탬프 사이의 시간 차이입니다. 세컨더리 노드가 프라이머리 노드와의 연결이 끊어지는 경우, oplog 윈도우(oplog window) 내에서 연결이 복원된 경우에만 복제를 사용하여 다시 동기화할 수 있습니다.

더 큰 Oplog 크기가 필요할 수 있는 워크로드

복제본 세트의 워크로드가 다음과 같은 패턴 중 하나와 유사할 것으로 예상되면, 기본값보다 큰 oplog를 생성하는 것이 좋을 수 있습니다. 반대로 애플리케이션에서 쓰기 작업을 최소화하면서 주로 읽기를 수행하는 경우에는 oplog가 작아도 충분할 수 있습니다.

다음과 같은 워크로드에는 더 큰 oplog 크기가 필요할 수 있습니다.

한 번에 여러 문서에 대한 업데이트

oplog는 다중 업데이트를 개별 작업으로 변환하여 멱등성을 유지해야 합니다. 이렇게 하면 데이터 크기나 디스크 사용량을 늘리지 않고도 많은 oplog 공간을 사용할 수 있습니다.

삭제는 삽입과 동일한 양의 데이터를 삭제합니다.

삽입한 것과 거의 같은 양의 데이터를 삭제하면 데이터베이스의 디스크 사용량이 크게 증가하지는 않지만 작업 로그의 크기는 상당히 커질 수 있습니다.

상당한 수의 인플레이스 업데이트

문서 크기를 늘리지 않는 업데이트가 워크로드의 상당 부분을 차지한다면, 데이터베이스는 많은 수의 작업을 기록하지만 디스크의 데이터 양은 변경하지 않습니다.

Oplog Status

oplog의 상태를 확인하고, 작업의 크기와 시간 범위를 포함한 정보를 보려면 rs.printReplicationInfo() 메서드를 실행합니다. oplog 상태에 대한 자세한 내용은 Oplog의 크기 확인을 참조하세요.

복제 지연 및 흐름 제어

여러 가지 예외적인 상황에서는 세컨더리 oplog에 대한 업데이트가 원하는 성능 시간보다 느릴 수 있습니다. 세컨더리 멤버의 db.getReplicationInfo() 와 복제 상태 출력을 사용하여 현재 복제 상태를 평가하고 의도하지 않은 복제 지연이 있는지 확인하세요.

MongoDB 4.2부터 관리자는 majority committed 지연을 구성 가능한 최대값 flowControlTargetLagSeconds이하로 유지하는 것을 목표로 기본이 쓰기를 적용하는 속도를 제한할 수 있습니다.

기본적으로 흐름 제어는 enabled 입니다.

참고

흐름 제어가 작동하려면 복제본 세트/샤딩된 클러스터에 4.2 의 featureCompatibilityVersion(fCV) 과 majority enabled의 읽기 우려 사항이 있어야 합니다. 즉, fCV가 4.2 가 아니거나 읽기 문제 과반수가 비활성화된 경우 활성화된 흐름 제어는 효과가 없습니다.

자세한 내용은 복제 지연을 참조하세요.

저속 oplog 애플리케이션

복제본 세트의 세컨더리 멤버는 적용하는 데 느린 작업 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이 메시지는 REPL구성 요소 아래에 세컨더리에 대해 logged되며, applied op: <oplog entry> took <num>ms라는 텍스트를 포함합니다

2018-11-16T12:31:35.886-05:00 I REPL   [repl writer worker 13] applied op: command { ... }, took 112ms

세컨더리 멤버에 대한 느린 oplog 애플리케이션은 다음과 같습니다.

느린 작업 임계값 설정에 대한 자세한 내용은 다음을 참조하세요.

Oplog 컬렉션 동작

drop MongoDB 배포에서 WiredTiger 스토리지 엔진을 사용하는 경우 복제 세트 구성원에서 local.oplog.rs컬렉션을 삭제할 수 없습니다. 또한 독립형 MongoDB 인스턴스에서도local.oplog.rs컬렉션을 삭제할 수 없습니다. mongod { 는 노드가 다운된 경우 노드의 복제 및 복구에 oplog가 필요하기 때문입니다.

MongoDB 5.0부터는 설정된 복제본 세트로 실행 중인 클러스터에서 oplog에 수동으로 쓰기 작업을 수행할 수 없습니다. 독립형 인스턴스로 실행할 때 oplog에 쓰기 작업을 수행하는 작업은 MongoDB 지원팀의 지침을 통해서만 수행해야 합니다.

돌아가기

복제