복제 지연 문제 해결

네트워크 지연 시간

클러스터 노드가 서로 안정적으로 통신할 수 없는 경우 복제 지연이 빌드 수 있습니다.

복제본 세트 멤버 간의 네트워크 경로를 확인하여 패킷 손실이나 네트워크 라우팅 문제가 없는지 확인합니다.

등의 도구를 사용하여 설정하다 멤버 간의 지연 시간 테스트하고 ping 을(를) traceroute 사용하여 네트워크 엔드포인트 간의 패킷 라우팅을 노출합니다.

또는 를 실행 replSetGetStatus 하고 pingMs 필드 검사합니다. 그러면 프라이머리 와 세컨더리 노드 간의 현재 네트워크 지연 시간 (밀리초)이 반환됩니다.

세컨더리 리소스 고갈

세컨더리 노드는 프라이머리 로부터 들어오는 읽기 작업을 효율적으로 처리하다 할 수 없을 때 리소스 경합을 경험할 수 있습니다. 이로 인해 캐시 경합과 같은 메모리 문제가 발생할 수 있습니다. 캐시 중요 임계값에 도달하면 서버 애플리케이션 스레드를 사용하여 페이지를 제거하므로 복제 관리 에 사용할 수 있는 스레드 수가 줄어듭니다.

서버 애플리케이션 스레드를 제거 작업으로 리디렉션하는지 확인하려면 mongosh 셸 에서 다음 명령을 실행 .

db.serverStatus().wiredTiger.cache['pages evicted by application threads']

• 결과 = 0 인 경우: 제거를 위해 일시 중지된 애플리케이션 스레드가 없습니다.

• 결과 >(및0 증가)인 경우: 데이터베이스 가 캐시 압력을 받고 있습니다. 수신 쿼리는 실행되기 전에 캐시된 데이터를 제거해야 하므로 복제 지연 증가할 수 있습니다.

Atlas 사용자는 WiredTiger Cache Activity 및 Page Faults 지표 모니터 캐시 관련 문제를 조사할 수도 있습니다.

이 문제를 해결하기 위한 잠재적인 전략은 리소스 확장을 참조하세요.

디스크 관련 문제

세컨더리 노드 더티 데이터를 디스크에 충분히 빠르게 플러시할 수 없으면 프라이 프라이머리 보다 뒤처집니다. 이 현상은 프라이머리 에서 발생하는 쓰기 볼륨이 세컨더리 디스크의 쓰기 (write) 속도를 초과할 때 발생합니다.

디스크 관련 문제는 가상화된 인스턴스를 포함한 멀티 테넌트 시스템에 일반적으로 존재하며, 시스템이 IP 네트워크를 통해 디스크 장치에 액세스하는 경우 일시적일 수 있습니다.

디스크 상태를 평가하려면 iostat 또는 vmstat과 같은 시스템 수준 도구를 사용합니다.

Atlas 사용자는 Disk IOPS 및 와 같은 Atlas 지표 액세스 디스크 Disk Space Used 문제를 조사할 수 있습니다.

디스크 문제의 몇 가지 일반적인 원인은 다음과 같습니다.

• 프로비저닝 부족: 세컨더리 프라이머리 보다 디스크 속도가 느리거나 IOPS가 낮습니다.

• 가상화 오버헤드: 공유 환경에서는 다른 가상 머신이 물리적 디스크 컨트롤러를 포화시킬 수 있습니다.

디스크 문제에 대한 몇 가지 가능한 해결책은 다음과 같습니다.

• 프로비저닝된 IOPS 증가

• NVMe 스토리지로업그레이드

• 더 높은 Atlas cluster 계층 으로 업그레이드합니다. 자세한 내용은 Atlas 클러스터 크기 조정 및 계층 선택을 참조하세요.

장기 실행 작업

경우에 따라 프라이머리에서 장기간 실행되는 작업으로 인해 세컨더리에서의 복제가 차단될 수 있습니다. 최적의 결과를 얻으려면 쓰기 고려를 구성하여 세컨더리로의 복제 확인이 필요하도록 설정할 수 있습니다. 이렇게 하면 복제가 쓰기 부하를 따라잡을 수 없는 경우 쓰기 작업이 반환되지 않습니다.

또한 데이터베이스 프로파일러 사용하여 관찰된 지연과 상관관계가 있는 느린 쿼리나 장기 실행 작업을 식별할 수 있습니다.

과도한 쓰기 로드

대량 쓰기 (write) 작업은 복제본 세트의 적시 복제 기능 초과하여 복제 지연 일으킬 수 있습니다.

다음 하위 섹션에서는 이 문제에 대한 가능한 해결책을 제공합니다.

db.collName.deleteMany({createdDate: {$gte: new Date("2018-12-01"), $lt: new Date("2019-01-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-11-01"), $lt: new Date("2018-12-01")}});
db.collName.deleteMany({createdDate: {$gte: new Date("2018-10-01"), $lt: new Date("2018-11-01")}});

db.collection.createIndex({ status: 1 });

db.collection.deleteMany({ status: "inactive" });

oplog 창 크기

동기화 중인 데이터의 양에 비해 oplog window 너무 작으면 복제 지연 발생할 수 있습니다.oplog 가 클수록 복제본 세트 의 지연에 대한 허용 오차가 커질 수 있습니다.

지정된 복제본 세트 멤버에 대한 oplog 의 크기와 해당 작업의 날짜 범위를 확인하려면 의 멤버에 mongosh rs.printReplicationInfo() 연결하고 메서드를 실행 . oplog 세컨더리 에서 예상하는 가장 긴 다운타임 동안 모든 트랜잭션을 보유할 수 있을 만큼 길어야 합니다. []1 최소한 oplog 최소 시간의 작업을 보유할 수 있어야 24 합니다. 그러나 많은 사용자는 72 시간 또는 일주일 분량의 작업을 선호합니다.

Oplog 크기를 변경하려면 자체 관리형 복제본 세트 멤버의 Oplog 크기 변경 튜토리얼을 참조하세요.