복제 세트 문제 해결
이 섹션에서는 복제본 세트 배포 문제를 해결하기 위한 일반적인 전략에 대해 설명합니다.
복제본 세트 상태 확인
복제본 세트의 현재 상태와 각 멤버의 현재 상태를 표시하려면 복제본 세트의 프라이머리에 연결된 mongosh 세션에서 rs.status() 메서드를 실행합니다. rs.status()가 표시하는 정보에 대한 설명은 replSetGetStatus를 참조하세요.
참고
rs.status() 메서드는 replSetGetStatus 데이터베이스 명령을 실행하는 래퍼(wrapper)입니다.
복제 지연 확인
복제 지연은 프라이머리상의 작업과 oplog에서 세컨더리로의 작업 적용 간의 지연입니다. 복제 지연은 심각한 문제가 될 수 있으며 MongoDB 복제본 세트 배포에 심각한 영향을 미칠 수 있습니다. 복제 지연이 너무 심하면 '지연된' 멤버가 신속하게 프라이머리 멤버가 될 수 없게 되고 분산 읽기 작업이 일관되지 않을 가능성이 커집니다.
현재 복제 지연 시간을 확인하려면 다음을 수행합니다.
프라이머리에 연결된
mongosh세션에서rs.printSecondaryReplicationInfo()메서드를 호출합니다.각 멤버에 대한
syncedTo값을 반환합니다. 이 값은 다음 예제와 같이 마지막 oplog 항목이 세컨더리 멤버에 기록된 시간을 보여줍니다.source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary 프라이머리 멤버의 비활성 기간이
members[n].secondaryDelaySecs값보다 큰 경우 지연된 멤버는 프라이머리 멤버보다0초 뒤처진 것으로 표시될 수 있습니다.참고
rs.status()메서드는replSetGetStatus데이터베이스 명령을 감싸는 래퍼(wrapper)입니다.MongoDB 6.0.13 부터 시작 ( 5.0.24), 느린 쿼리 로그 메시지의
totalOplogSlotDurationMicros는 쓰기 작업에서 커밋 타임스탬프를 가져와 스토리지 엔진 쓰기를 커밋한 후 실제로 커밋하기까지의 시간을 보여줍니다.mongod는 병렬 쓰기를 지원합니다. 그러나 커밋 타임스탬프가 있는 쓰기 작업은 순서에 관계없이 커밋합니다.예시
커밋 타임스탬프가 있는 다음 쓰기를 생각해 보세요.
타임스탬프1이 있는 writeA
타임스탬프2를 사용한 writeB
타임스탬프3을 사용한 writeC
writeB가 Timestamp2에서 처음으로 커밋한다고 가정합니다. 복제에서 oplog를 보조 복제 세트 멤버로 복제하려면 Timestamp1이 포함된 WriteA의 oplog 항목이 필요하기 때문에 WriteA가 커밋할 때까지 복제가 일시 중지됩니다.
Cloud Manager 및 Ops Manager에서 사용할 수 있는 Replication Lag 그래프에서 0이 아니거나 증가하는 oplog 시간 값을 확인하여 복제 속도를 모니터링합니다.
복제 지연 원인
복제 지연의 원인으로는 원인은 다음이 해당할 수 있습니다.
네트워크 지연 시간
세트 멤버 간의 네트워크 경로를 확인하여 패킷 손실이나 네트워크 라우팅 문제가 없는지 확인합니다.
ping등의 도구를 사용하여 집합 멤버 간의 지연 시간을 테스트하고traceroute을 사용하여 패킷 네트워크 엔드포인트의 라우팅을 노출할 수 있습니다.디스크 처리량
세컨더리의 파일 시스템과 디스크 장치가 프라이머리처럼 데이터를 디스크로 빠르게 플러시할 수 없는 경우 상태를 유지하기 어렵습니다. 디스크 관련 문제는 가상화된 인스턴스를 포함한 멀티테넌트 시스템에 매우 빈번하게 발생하며 시스템이 IP 네트워크를 통해 디스크 장치에 액세스하는 경우(예: Amazon의 EBS 시스템) 일시적으로 발생할 수 있습니다.
iostat또는vmstat을 포함한 시스템 수준 도구를 사용하여 디스크 상태를 평가합니다.동시성
경우에 따라 프라이머리에서 장기간 실행되는 작업으로 인해 세컨더리에서의 복제가 차단될 수 있습니다. 최적의 결과를 얻으려면 쓰기 고려를 구성하여 세컨더리로의 복제 확인이 필요하도록 설정할 수 있습니다. 이렇게 하면 복제가 쓰기 부하를 따라잡을 수 없는 경우 쓰기 작업이 반환되지 않습니다.
또한 데이터베이스 프로파일러를 사용하여 지연 발생에 해당하는 느린 쿼리나 장기 실행 작업이 있는지 확인할 수도 있습니다.
적절한 쓰기 고려
특히
unacknowledged write concern와 같이 프라이머리에 많은 수의 쓰기가 필요한 대규모 데이터 수집 또는 대량 로드 작업을 수행하면 세컨더리에서는 변경 사항을 따라잡을 수 있을 만큼 충분히 빠르게 oplog를 읽을 수 없게 됩니다.이를 방지하려면 100회, 1,000회 또는 다른 간격마다 쓰기 고려 승인 작성을 요청하여 세컨더리가 프라이머리를 따라잡을 수 있는 기회를 제공합니다.
자세한 내용은 다음을 참조하세요.
흐름 제어
MongoDB 4.2부터 관리자는 majority
committed 지연을 구성 가능한 최대값 flowControlTargetLagSeconds이하로 유지하는 것을 목표로 기본이 쓰기를 적용하는 속도를 제한할 수 있습니다.
기본적으로 흐름 제어는 enabled 입니다.
참고
흐름 제어가 작동하려면 복제본 세트/샤딩된 클러스터에 4.2 의 featureCompatibilityVersion(fCV) 과 majority enabled의 읽기 우려 사항이 있어야 합니다. 즉, fCV가 4.2 가 아니거나 읽기 문제 과반수가 비활성화된 경우 활성화된 흐름 제어는 효과가 없습니다.
흐름 제어가 활성화되면 지연이 flowControlTargetLagSeconds 에 가까워짐에 따라 기본에 대한 쓰기는 쓰기를 적용하기 위해 잠금을 수행하기 전에 티켓을 얻어야 합니다. 초당 발행되는 티켓 수를 제한함으로써 흐름 제어 메커니즘은 지연을 목표 미만으로 유지하려고 시도합니다.
복제본 세트가 흐름 제어를 시작할 수 있을 만큼 충분한 로드를 받지 못하면 복제 지연이 발생할 수 있습니다(예: 응답하지 않는 세컨더리 복제본의 경우).
흐름 제어 상태를 보려면 프라이머리에서 다음 명령을 실행합니다.
rs.printSecondaryReplicationInfo()메서드를 실행하여 지연되고 있는 노드가 있는지 확인합니다.rs.printSecondaryReplicationInfo() 출력 예시:
source: 192.0.2.2:27017 { syncedTo: 'Mon Jan 31 2022 18:58:50 GMT+0000 (Coordinated Universal Time)', replLag: '0 secs (0 hrs) behind the primary ' } --- source: 192.0.2.3:27017 { syncedTo: 'Mon Jan 31 2022 18:58:05 GMT+0000 (Coordinated Universal Time)', replLag: '45 secs (0 hrs) behind the primary ' } serverStatus명령을 실행하고flowControl.isLagged값을 사용하여 다음과 같이 복제본 세트에 흐름 제어가 적용되었는지 여부를 확인합니다.db.runCommand( { serverStatus: 1 } ).flowControl.isLagged 출력 예시:
false 흐름 제어가 작동하지 않는 경우 세컨더리를 조사하여 하드웨어, 네트워크 또는 애플리케이션상의 제약과 같은 복제 지연의 원인을 파악하세요.
플로우 제어 통계에 대한 자세한 내용은 다음을 참조하세요.
Oplog 항목 지연 적용
이제 복제본 세트의 세컨더리 멤버가 느린 작업 임곗값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
diagnostic log에 세컨더리 멤버에 대해 기록합니다.applied op: <oplog entry> took <num>ms텍스트와 함께REPL구성 요소 아래에 기록됩니다.로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.
프로파일링 수준에 의존하지 않습니다.
slowOpSampleRate의 영향을 받습니다.
프로파일러는 느린 oplog 항목을 캡처하지 않습니다.
모든 멤버 간 연결 테스트
복제본 세트의 모든 구성원이 복제를 지원하려면 세트의 다른 모든 멤버에 연결할 수 있어야 합니다. 항상 '양방향'으로 연결을 확인하세요. 네트워킹 토폴로지와 방화벽 구성으로 인해 정상적인 필수 연결이 차단되어 복제를 차단할 수 있습니다.
경고
로컬 호스트가 아닌 에 바인딩하기 전에(예: 공개적으로 액세스할 수 있는) IP 주소 인 경우 무단 액세스 로부터 클러스터 를 보호했는지 확인합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버를 위한 보안 체크리스트를 참조하세요. 최소한 인증 을 활성화 하고 네트워크 인프라를 강화하는 것을 고려하세요.
2} 및mongod MongoDB mongos 바이너리는 기본적으로 로컬 호스트에 바인딩됩니다. 바이너리에 대해 net.ipv6 구성 파일 설정 또는 --ipv6 명령줄 옵션이 설정되어 있으면 바이너리가 로컬 호스트 IPv6 주소에 추가적으로 바인딩됩니다.
기본적으로 로컬 호스트에 바인딩된 mongod 및 mongos는 동일한 컴퓨터에서 실행 중인 클라이언트의 연결만 허용합니다. 이 바인딩 동작에는 mongosh 및 복제본 집합 또는 샤딩된 클러스터의 다른 멤버가 포함됩니다. 원격 클라이언트는 로컬 호스트에만 바인딩된 바이너리에는 연결할 수 없습니다.
기본 바인딩을 재정의하고 다른 IP 주소에 바인딩하려면 net.bindIp 구성 파일 설정 또는 --bind_ip 명령줄 옵션을 사용하여 호스트 이름 또는 IP 주소 목록을 지정합니다.
경고
MongDB 부터 5.0 시작, 분할 수평 DNS IP 주소로만 구성된 노드는 시작 유효성 검사에 실패하고 오류를 보고합니다. disableSplitHorizonIPCheck 를 참조하세요.
예를 들어 다음 mongod 인스턴스는 로컬 호스트와 IP 주소 198.51.100.1 와 연결된 호스트명 My-Example-Associated-Hostname에 모두 바인딩됩니다.
mongod --bind_ip localhost,My-Example-Associated-Hostname
이 인스턴스에 연결하려면 원격 클라이언트가 호스트 이름 또는 관련 IP 주소 198.51.100.1를 지정해야 합니다.
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
네트워킹의 양방향 테스트에 대한 다음 예시를 살펴보겠습니다.
예시
세 개의 호스트에서 실행되는 세 명의 멤버로 구성된 복제본 세트가 있습니다.
m1.example.netm2.example.netm3.example.net
세 개 모두 기본 포트 27017을 사용합니다.
다음
m1.example.net작업 집합을 사용하여m1.example.net에서 다른 호스트로의 연결을 테스트합니다.mongosh --host m2.example.net --port 27017 mongosh --host m3.example.net --port 27017 다음과 같이
m2.example.net의 작업 세트를 사용하여m2.example.net에서 다른 두 호스트로의 연결을 테스트합니다.mongosh --host m1.example.net --port 27017 mongosh --host m3.example.net --port 27017 m2.example.net와m1.example.net간 양방향 연결 테스트가 완료되었습니다.다음과 같이
m3.example.net의 작업 세트를 사용하여m3.example.net호스트에서 다른 두 호스트로의 연결을 테스트합니다.mongosh --host m1.example.net --port 27017 mongosh --host m2.example.net --port 27017
어떤 방향으로든 연결에 장애가 발생하면 네트워킹 및 방화벽 구성을 확인하고 이러한 연결을 허용하도록 환경을 재구성하세요.
둘 이상의 세컨더리 복제본을 재부팅할 때 소켓 예외
복제본 세트 멤버를 재부팅할 때는 유지 관리 중에 해당 세트가 프라이머리를 선택할 수 있는지 확인하세요. 즉, 세트의 members[n].votes 대부분을 사용할 수 있도록 설정해야 합니다.
세트의 활성 멤버가 더 이상 과반수를 구성할 수 없게 되면 세트의 프라이머리 멤버가 세컨더리 멤버로 강등됩니다. 프라이머리는 강등 시 클라이언트 연결을 종료하지 않습니다.
클라이언트는 멤버가 새 프라이머리를 선출할 때까지 복제본 세트에 쓸 수 없습니다.
예시
3개의 멤버가 한 표를 갖고 있는 복제본 집합의 경우 최소 두 명의 구성원이 서로 연결할 수 있으면 이 집합은 프라이머리를 선출할 수 있습니다. 두 개의 세컨더리를 동시에 재부팅하면 프라이머리가 강등되어 세컨더리가 됩니다. 다른 세컨더리 복제본을 사용할 수 있게 될 때까지(즉, 재부팅된 세컨더리 복제본 중 하나 이상을 사용할 수 있게 될 때까지) 해당 세트에는 프라이머리 복제본이 존재하지 않으며 새 프라이머리 복제본을 선택할 수 없습니다.
투표에 대한 자세한 내용은 복제본 세트 선거를 참조하세요. 연결 오류에 대한 관련 정보는 TCP keepalive 시간이 MongoDB 배포에 영향을 미치나요?를 참조하세요.
Oplog의 크기 확인
oplog가 클수록 레플리카 세트의 지연에 대한 허용 오차가 커지고 세트의 복원력이 향상될 수 있습니다.
주어진 복제본 세트 멤버에 대한 oplog의 크기를 확인하려면 mongosh에서 멤버에 연결하여 rs.printReplicationInfo() 메서드를 실행합니다.
출력에는 oplog의 크기와 oplog에 포함된 작업의 날짜 범위가 표시됩니다. 다음 예시의 oplog는 약 10MB이며 약 26시간(94400초)의 작업을 수행할 수 있습니다.
configured oplog size: 10.10546875MB log length start to end: 94400 (26.22hrs) oplog first event time: Mon Mar 19 2012 13:50:38 GMT-0400 (EDT) oplog last event time: Wed Oct 03 2012 14:59:10 GMT-0400 (EDT) now: Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)
oplog는 보조 서버에서 예상하는 가장 긴 가동 중지 시간 동안 모든 트랜잭션을 보관할 수 있을 만큼 길어야 합니다. [1] oplog는 최소 24시간 동안 운영할 수 있으나 72시간 또는 일주일 동안 운영하기를 원하는 사용자가 많습니다.
oplog 크기가 작업에 미치는 영향에 대한 자세한 내용은 다음을 참조하세요.
참고
일반적으로 oplog는 모든 멤버에서 동일한 크기여야 합니다. oplog의 크기를 조정하는 경우 모든 멤버에서 크기를 조정하세요.
Oplog 크기를 변경하려면 자체 관리형 복제본 세트 멤버의 Oplog 크기 변경 튜토리얼을 참조하세요.
| [1] | 2}가 삭제되는 것을 방지하기 위해 oplog가 구성된 크기 제한을 초과하여 커질 수 majority commit point 있습니다. |