빈번한 투표 문제 해결

복제본 세트는 프라이머리 머리가 강등되거나 사용할 수 없게 되면 투표를 실행 경우가 있습니다. 투표 중에는 복제본 세트 새 프라이머리 성공적으로 선택할 때까지 쓰기를 허용할 수 없지만, 구성된 경우 대부분의 읽기는 세컨더리에서 계속될 수 있습니다.

드문 페일오버 또는 계획된 유지 관리 중에 이 동작이 발생할 수 있습니다. 그러나 정상 작동 중에 프라이머리 자주 변경되는 빈번한 선택으로 인해 쓰기 (write) 중단이 반복되고 경우에 따라 커밋되지 않은 데이터의 롤백이 발생합니다.

이 페이지에는 빠른 진단을 보장하고 애플리케이션 쓰기 (write) 중단을 방지하기 위해 빈번한 투표에 대한 일반적인 문제와 해결 방법이 포함되어 있습니다. 다음 섹션을 검토한 후 추가 지원 필요한 경우 기술 지원에 문의 .

전제 조건 검사

정상 클러스터는 드물게 예상되는 이벤트 중에만 투표를 볼 수 있습니다. 투표는 일반적으로 다음 시나리오에서 발생합니다.

초기 설정
유지 관리 작업(예:rs.stepDown() 또는) rs.reconfig()
신규 멤버 추가: rs.add()
구성된 timeout를 초과하여 프라이머리 사용 불가( 기본값 은 10 초)

한 시간 이내 또는 하루 종일과 같이 설정하다 기간 동안replSetGetStatus또는rs.status()메서드를 여러 번 실행 배포서버 이러한 시나리오 외에 선거가 자주 발생하는지 확인합니다. 보고된 프라이머리의 _id 값을 매번 비교하여 프라이머리 노드 변경되어 투표 발생했음을 의미하는지 여부와 시기 추적 합니다.

참고

Ops Manager 에 TOO_MANY_ELECTIONS 경고 표시되면 투표가 자주 발생하기 때문일 수 있습니다.

로그 메시지 확인

구성 요소()"c" 값이 인 항목에 대한 배포 ELECTION 로그 메시지를 참조할 수도 있습니다. 계획된 유지 관리 없이 시간당 또는 하루에 여러 번과 같이 짧은 간격으로 로그에 다음 메시지가 여러 번 표시되면 일반적으로 네트워크 불안정, 비정상적인 호스트 또는 잘못된 구성으로 인해 비정상적인 복제본 세트 발생했음을 나타냅니다.

메시지	설명
" 투표 시간 초과 기간에 PRIMARY가 발생하지 않았으므로 투표 시작"	프라이머리 머리가 물러날 때 다른 멤버가 기록합니다.
"SECONDARY에서 PRIMARY로 전환"	새로운 프라이머리 인계받습니다.
" 설정하다 의 과반수를 볼 수 없으며, 프라이 프라이머리 포기합니다 "	이전 프라이머리 는 세컨더리 됩니다.

일반적인 문제 및 해결 방법

다음 섹션에서는 복제본 세트 예기치 않게 빈번한 투표를 수행할 수 있는 일반적인 문제에 대해 설명합니다. 지원 문의 하기 전에 다음과 같은 위험으로 인해 복제본 세트 가 자주 선택되는지 확인하세요.

리소스 고갈

집약적인 쿼리, 대규모 애그리게이션, 인덱스 빌드 또는 백업과 같은 배경 작업은 높은 CPU 사용량, 디스크 지연 시간 또는 장애, 메모리 압박을 초래할 수 있습니다. 리소스가 고갈되면 프라이머리 응답하지 않거나 하트비트를 제때 프로세스 할 수 없기 때문에 투표가 자주 발생할 수 있습니다.

비효율적인 쿼리

비효율적인 쿼리로 인해 배포서버 리소스 고갈되는지 확인하려면 다음을 수행합니다.

로그에서 구성 요소("c") 값이 인 항목을 COMMAND 찾습니다.
각 항목에 대해 bytesRead 필드 지정된 명령이 읽는 바이트 수를 나타냅니다. bytesRead 값이 큰 명령에 주의하세요.
비효율적인 쿼리의 타임스탬프가 다중 투표의 타임스탬프 근처에 있는 경우 비효율적인 쿼리로 인해 투표가 자주 발생할 수 있습니다.

다음 리소스를 사용하여 쿼리를 최적화하세요.

복합 인덱스를사용하여 워크로드 보다 효율적으로 처리합니다.
새 인덱스를 생성하려면 ESR 가이드라인을 검토하세요.
Atlas 에서 Performance Advisor를 정기적으로 검토 최신 워크로드 기반으로 한 인덱스 제안을 확인합니다.

복제본 세트의 잘못된 구성

노드 우선순위

복제본 세트는 우선 순위 가장 높은 멤버를 선택할 때까지 지속적으로 호출 투표를 실시합니다. 멤버 우선 순위를 적절하게 설정하다 하지 않으면 투표가 더 자주 발생하여 예기치 않은 멤버가 프라이머리 될 수 있습니다.

각 멤버의 우선 순위 값을 확인하려면 replSetGetConfig 명령 또는 메서드를 실행 rs.conf() rs.conf() . 다음 예시 우선순위가 잘못 구성된 복제본 세트 에 대한 메서드의 출력을 보여줍니다.

rs.conf().members

[
   {
      _id: 0,
      host: "rs0-0.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: { dc: "primaryDC" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 1,
      host: "rs0-1.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 10,
      tags: { dc: "remoteDC1" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 2,
      host: "rs0-2.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 9,
      tags: { dc: "remoteDC2" },
      secondaryDelaySecs: Long(0),
      votes: 1
   },
   {
      _id: 3,
      host: "rs0-3.example.net:27017",
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 8,
      tags: { dc: "analyticsDC" },
      secondaryDelaySecs: Long(0),
      votes: 1
   }
]

위의 예시 에서 현재 프라이머리 다른 세 멤버보다 우선 순위 낮습니다. 우선 순위가 높은 세컨더리 정상이고 SECONDARY 상태 인 경우 프라이머리 로 인계받기 위한 투표 트리거하다 될 수 있습니다.

복제본 세트 멤버의 우선 순위를 적절하게 구성해야 합니다.

지속적으로 프라이머리 로 제공 서버 에 가장 높은 우선 순위 할당합니다.
다른 멤버에게 기본값 또는 더 낮은 우선 순위를 할당하여 프라이머리 될 가능성을 줄입니다.
복제 지연 높은 노드에 우선 우선 순위 할당합니다.

복제본 세트 설정

복제본 세트 구성 replSetGetConfig 설정을 확인하려면 명령 또는 메서드를 실행 . 다음 예시 가 rs.conf() electionTimeoutMillis 너무 낮게 구성된 복제본 세트 보여줍니다.

rs.conf().settings

{
   chainingAllowed: true,
   heartbeatIntervalMillis: 2000,
   heartbeatTimeoutSecs: 10,
   electionTimeoutMillis: 1500,   // lower than a single heartbeat cycle
   catchUpTimeoutMillis: 2000,
   getLastErrorModes: { },
   getLastErrorDefaults: {
      w: 1,
      wtimeout: 0
   },
   replicaSetId: ObjectId("58858acc1f5609ed986b641b")
}

의 settings.electionTimeoutMillis 값이 너무 낮지 않은지 확인합니다. 위의 예시 에서 settings.electionTimeoutMillis 값은 보다 settings.heartbeatIntervalMillis 낮습니다. 즉, 전체 하트비트 간격이 완료되기 전에 노드 프라이머리 "다운"을 선언하여 불필요한 투표를 일으킬 수 있습니다.

네트워크 분할 또는 지연 시간

배포서버 에 네트워크 파티션 발생하거나 노드에 하트비트 메시지 지연이 발생하는 경우 세컨더리는 프라이머리 사용할 수 없는 것으로 잘못 보고 투표를 시작할 수 있습니다.

네트워크 파티션이 발생하는지 확인하려면 다음 단계를 따르세요.

로그에서 다음 메시지가 자주 나타나는지 확인합니다.

메시지	설명
" 투표 시간 초과 기간에 PRIMARY가 발생하지 않았으므로 투표 시작"	세컨더리 구성된 제한 창 내에 프라이머리 로부터 하트비트를 받지 못했기 때문에 투표 시작했습니다.
" 설정하다 의 과반수를 볼 수 없으며, 프라이 프라이머리 포기합니다 "	프라이머리 투표권이 있는 세컨더리 과반수와 통신할 수 없기 때문에 물러났습니다.

다른 rs.status() 노드에서 또는 를 실행하여 어떤 멤버에 연결할 수 있는지에 대한 다양한 보기를 표시하며, 이는 노드의 하위 집합이 분할 나타냅니다.replSetGetStatus

파티션 후 연결을 복원 하려면 다음을 수행합니다.

방화벽 구성에서 구성원 간의 통신을 차단 수 있는 규칙이 있는지 확인합니다.
DNS 호스트 이름을 확인합니다.
IP 액세스 목록에 IP 주소 추가했는지 확인합니다.

해결 방법 확인

근본 원인을 주소 후 rs.status()를 다시 실행하여 투표가 자주 발생하지 않는지 확인합니다. 출력에는 프라이머리 상태 의 멤버가 정확히 하나만 표시되며, 프라이머리 계획되지 않은 변경 없이 정상적인 관찰 창 동안 안정적으로 유지됩니다.

배포서버 로그를 참조할 수도 있습니다. 배포서버 로그에서 위에 나열된 로그 메시지를 찾아 투표가 짧은 간격에 걸쳐 여러 번 발생하지 않도록 합니다.

추가 지원을 위해 수집할 진단

여전히 문제를 해결할 수 없는 경우 다음 진단 정보를 가지고 기술 지원에 문의 .

영향을 받은 기간의 관련 로그 메시지
rs.config() 출력
rs.status() 출력

자세히 알아보기

돌아가기

복제본 세트 프로토콜 버전

복제본 세트 프라이머리 없음