복제 세트 문제 해결

복제본 세트 상태 확인

복제본 세트의 현재 상태와 각 멤버의 현재 상태를 표시하려면 복제본 세트의 프라이머리에 연결된 mongosh 세션에서 rs.status() 메서드를 실행합니다. rs.status()가 표시하는 정보에 대한 설명은 replSetGetStatus를 참조하세요.

복제 지연 확인

복제 지연은 프라이머리상의 작업과 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 7.0 (및 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 시간 값을 확인하여 복제 속도를 모니터링합니다.

Oplog 항목 지연 적용

이제 복제본 세트의 세컨더리 멤버가 느린 작업 임곗값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.

• diagnostic log에 세컨더리 멤버에 대해 기록합니다.

• applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.

• 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.

• 프로파일링 수준에 의존하지 않습니다.

• slowOpSampleRate의 영향을 받습니다.

프로파일러는 느린 oplog 항목을 캡처하지 않습니다.

모든 멤버 간 연결 테스트

복제본 세트의 모든 구성원이 복제를 지원하려면 세트의 다른 모든 멤버에 연결할 수 있어야 합니다. 항상 '양방향'으로 연결을 확인하세요. 네트워킹 토폴로지와 방화벽 구성으로 인해 정상적인 필수 연결이 차단되어 복제를 차단할 수 있습니다.

2} 및mongod MongoDB mongos 바이너리는 기본적으로 로컬 호스트에 바인딩됩니다. 바이너리에 대해 net.ipv6 구성 파일 설정 또는 --ipv6 명령줄 옵션이 설정되어 있으면 바이너리가 로컬 호스트 IPv6 주소에 추가적으로 바인딩됩니다.

기본적으로 로컬 호스트에 바인딩된 mongod 및 mongos는 동일한 컴퓨터에서 실행 중인 클라이언트의 연결만 허용합니다. 이 바인딩 동작에는 mongosh 및 복제본 집합 또는 샤딩된 클러스터의 다른 멤버가 포함됩니다. 원격 클라이언트는 로컬 호스트에만 바인딩된 바이너리에는 연결할 수 없습니다.

기본 바인딩을 재정의하고 다른 IP 주소에 바인딩하려면 net.bindIp 구성 파일 설정 또는 --bind_ip 명령줄 옵션을 사용하여 호스트 이름 또는 IP 주소 목록을 지정합니다.

예를 들어 다음 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

네트워킹의 양방향 테스트에 대한 다음 예시를 살펴보겠습니다.

둘 이상의 세컨더리 복제본을 재부팅할 때 소켓 예외

복제본 세트 멤버를 재부팅할 때는 유지 관리 중에 해당 세트가 프라이머리를 선택할 수 있는지 확인하세요. 즉, 세트의 members[n].votes 대부분을 사용할 수 있도록 설정해야 합니다.

세트의 활성 멤버가 더 이상 과반수를 구성할 수 없게 되면 세트의 프라이머리 멤버가 세컨더리 멤버로 강등됩니다. 프라이머리는 강등 시 클라이언트 연결을 종료하지 않습니다.

클라이언트는 멤버가 새 프라이머리를 선출할 때까지 복제본 세트에 쓸 수 없습니다.

투표에 대한 자세한 내용은 복제본 세트 선거를 참조하세요. 연결 오류에 대한 관련 정보는 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 크기 변경 튜토리얼을 참조하세요.