AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

oplog 문제 해결

프라이머리 클러스터 멤버에서 생성된 oplog 데이터의 양이 클러스터의 설정된 oplog 크기보다 클 때 복제 Oplog 경고가 트리거될 수 있습니다.

프로젝트 수준 경고 설정 페이지에서 다음과 같은 경고 조건을 구성하여 경고를 트리거할 수 있습니다.

Replication Oplog Window is (X) 프라이머리 복제 oplog에서 사용 가능한 대략적인 시간이 지정된 임계값을 충족하거나 그 이하로 떨어지는 경우 발생합니다. 이는 oplog 데이터가 생성되는 현재 속도를 고려하여 프라이머리가 로깅을 계속할 수 있는 시간을 나타냅니다.

Oplog Data Per Hour is (X) 프라이머리 서버의 복제 oplog에 기록되는 시간당 데이터 양이 지정된 임계값을 충족하거나 초과하는 경우 발생합니다.

다음은 oplog 활동 증가로 이어질 수 있는 몇 가지 일반적인 이벤트입니다:

  • 짧은 시간 내에 발생한 집중적인 쓰기 및 업데이트 작업.

  • 클러스터의 구성된 oplog 크기가 클러스터 지표 뷰에서 관찰된 Oplog GB / Hour 그래프의 값보다 작습니다.

복제 Oplog 경고를 해결하는 데 도움이 되는 몇 가지 작업은 다음과 같습니다.

  • 클러스터 지표 보기 내 Oplog GB / Hour 그래프의 피크 값보다 커지도록 클러스터의 구성을 편집하여 oplog 크기를 늘립니다.

  • 짧은 기간 동안 집중적인 쓰기 및 업데이트 작업이 발생할 것으로 예상되면 oplog 크기를 늘립니다.

    참고

    클러스터의 스토리지를 늘려서 oplog의 크기를 조정할 수 있는 충분한 공간을 확보해야 합니다.

  • Ensure that all write operations specify a write concern of majority to ensure that writes are replicated to at least one node before moving on to the next write operation. This controls the rate of traffic from your application by preventing the primary from accepting writes more quickly than the secondaries can handle.

    Atlas Infinite 클러스터에서 저장 계층은 데이터를 복제하며 majority은(는) 클러스터 노드의 과반수가 아닌 저장 계층 내의 과반수를 의미합니다. 자세한 내용은 Atlas Infinite 클러스터의 쓰기 고려 (write concern)를 참조하세요.

To learn about oplog sizing requirements for your use case, see Workloads that Might Require a Larger Oplog Size.

Atlas Infinite 클러스터에서는 oplog 크기를 설정할 수 없습니다. Atlas가 이러한 클러스터에서 oplog를 관리하는 방법에 대한 자세한 내용은 Atlas Infinite 클러스터의 oplog를 참조하세요.

이러한 알림이 트리거되는 경우 다음과 같은 시나리오가 발생할 수 있습니다:

  • 지표 보기의 Oplog GB / Hour 그래프가 위쪽으로 치솟습니다.

  • 지표 보기의 Replication Oplog Window 그래프가 낮습니다.

  • The Atlas View and Download MongoDB Logs of secondary or unhealthy nodes display the following message:

    We are too stale to use <node>:27017 as a sync source.
  • An Atlas node is reporting a state of STARTUP2 and RECOVERING for an extended period of time.

    Typically, this indicates that the node has "fallen off the oplog" and is unable to keep up with the oplog data being generated by the primary node. In this case, the node will require an initial sync in order to recover and ensure that the data is consistent across all nodes. You can check the state of a node using the rs.status() shell method.