환경설정 사용 사례 읽기

읽기 설정 모드

비프라이머 읽기 환경 설정을 사용해야 하는 표시

다음은 primary 이외의 읽기 설정 모드를 사용하는 일반적인 사용 사례입니다.

• 프런트엔드 애플리케이션에 영향을 주지 않는 시스템 작업 실행.

  참고

  읽기 설정은 단일 mongod 인스턴스에 대한 직접 연결과 관련이 없습니다. 그러나 복제본 세트의 세컨더리 멤버에 대한 직접 연결에서 읽기 작업을 수행하려면 세컨더리와 같은 읽기 설정을 설정해야 합니다.

• 지리적으로 분산된 애플리케이션에 로컬 읽기 기능을 제공합니다.

  여러 데이터 센터에 애플리케이션 서버가 있는 경우, 지리적으로 분산된 복제본 세트를 만들고 프라이머리가 아닌 nearest 읽기 설정을 사용하는 것을 고려할 수 있습니다. 이를 통해 클라이언트는 항상 프라이머리 멤버에서 읽는 대신 지연 시간이 가장 짧은 멤버에서 읽을 수 있습니다.

• 장애 조치 중 가용성 유지 페일오버.

  일반적인 primaryPreferred 상황에서는 애플리케이션이 프라이머리에서 읽지만, 프라이머리를 사용할 수 없을 때 세컨더리에서 오래된 읽기 를 허용하려면 를 사용합니다.

비프라이머 읽기 설정을 사용해야 하는 반대 표시

일반적으로 다음의 이유로 secondary 및secondaryPreferred사용하여 읽기 용량을 추가로 제공하지 않는 것이 좋습니다. :

• 복제본의 모든 노드가 거의 동일한 쓰기 트래픽을 받기 때문에 세컨더리 노드는 프라이머리와 거의 같은 속도로 읽기를 서비스합니다.

• 복제는 비동기식이며, 성공적인 쓰기 작업과 세컨더리에 대한 복제 사이에는 약간의 지연이 있습니다. 세컨더리 서버에서 읽으면 오래된 데이터가 반환될 수 있고, 다른 세컨더리 서버에서 읽으면 비단조적 읽기가 발생할 수 있습니다.

  버전 3.6에서 변경됨: MongoDB 3.6부터, 클라이언트는 클라이언트 세션과 인과적 일관성 보장을 사용하여 단조적 읽기를 보장할 수 있습니다.

• 일부 노드를 사용할 수 없을 경우 나머지 노드가 모든 애플리케이션 요청을 처리해야 하므로, 세컨더리 노드로 읽기 작업을 분산시키는 것은 위험할 수 있습니다.

샤딩은 읽기 및 쓰기 작업을 여러 머신 그룹에 분산하여 읽기 및 쓰기 용량을 늘리므로 용량을 추가하는 데 더 나은 전략인 경우가 많습니다.

읽기 설정의 내부 적용에 대한 자세한 내용은 서버 선택 알고리즘을 참조하세요.

일관성 극대화

오래된 데이터 읽는 것을 방지하려면 primary 읽기 설정과 "majority"를 사용합니다. readConcern. 프라이머리를 사용할 수 없는 경우 (예: 선거 중이거나 복제본 세트의 대부분에 접근할 수 없는 경우), primary 읽기 설정을 사용하는 읽기 작업은 오류를 발생시키거나 예외를 던질 것입니다.

일부 상황에서는 복제본 세트에 일시적으로 두 개의 프라이머리가 있을 수 있지만, "majority" 쓰기 고려로 쓰기를 확인할 수 있는 프라이머리는 하나뿐입니다.

• 부분 네트워크 파티션은 프라이머리 파티션(P _old)를 소수 노드가 있는 파티션으로 격리할 수 있으며, 파티션의 다른 쪽에는 노드의 대부분이 있을 수 있습니다. 과반수를 차지한 파티션은 새 프라이머리(P _new)를 선출하지만, 잠시 동안 이전 프라이머리(P _old)복제본 세트에서 소수의 노드만 볼 수 있다는 것을 감지하지 못했을 수 있으므로 계속해서 읽기 및 쓰기 작업을 처리할 수 있습니다. 이 기간 동안 이전 프라이머리(P_old)가 여전히 클라이언트에 프라이머리로 표시되는 경우 이 프라이머리에서 읽은 데이터는 오래된 데이터를 반영할 수 있습니다.

• 프라이머리 (P _old) 가 응답하지 않을 수 있고, 새 프라이머리 (P _new) 선출을 위한 투표가 진행되며, 이 새 프라이머리는 읽기 및 쓰기 작업을 담당하게 됩니다. 응답하지 않던 프라이머리 (P _old)가 다시 응답하기 시작하면 잠시 동안 프라이머리 두 개가 표시됩니다. 이 짧은 기간은 P _old가 자리에서 물러나면 종료됩니다. 그러나 이 기간 동안 클라이언트는 이전 프라이머리 P _old로부터 데이터를 읽게 되며, 이 때 오래된 데이터를 받을 수 있습니다.

일관성을 높이기 위해 자동 페일오버 기능을 비활성화할 수 있지만, 이 경우 시스템의 가용성이 저하될 수 있습니다.

가용성 극대화

가능한 경우 읽기 작업을 허용하려면 primaryPreferred 를 사용합니다. 프라이머리가 있으면 일관된 읽기 [1] 를 얻을 수 있지만, 프라이머리가 없는 경우에도 세컨더리 를 쿼리할 수 있습니다. 그러나 이 읽기 모드를 사용할 때는 secondary 대 secondaryPreferred 에 설명된 상황을 고려하세요.

지연 시간 최소화

항상 지연 시간이 짧은 노드에서 읽으려면 nearest를 사용하세요. 드라이버나 mongos는 가장 가까운 노드와 가장 가까운 노드보다 15밀리초[2] 미만 떨어져 있는 노드에서 읽습니다.

nearest는 일관성을 보장하지 않습니다. 애플리케이션 서버에 가장 가까운 멤버가 복제 지연이 있는 세컨더리 멤버인 경우 쿼리에서 오래된 데이터가 반환될 수 있습니다. nearest는 네트워크 거리만 반영하며 I/O 또는 CPU 부하를 반영하지 않습니다.

지리적으로 분산된 노드의 쿼리

복제본 세트의 노드들이 지리적으로 여러 곳에 분포되어 있다면, 노드의 위치를 반영하는 복제 태그를 만들어 애플리케이션을 구성함으로써 주변 노드들에 대한 쿼리 수행을 용이하게 할 수 있습니다.

예를 들어 '동부' 및 '서부' 데이터 센터의 노드에 {'dc': 'east'} 및 {'dc': 'west'} 태그가 지정되어 있는 경우 동부 데이터 센터의 애플리케이션 서버는 다음과 같은 읽기 설정을 통해 주변 노드에서 읽을 수 있습니다.

db.collection.find().readPref('nearest', [ { 'dc': 'east' } ])

nearest는 이미 네트워크 지연 시간이 짧은 노드를 선호하지만 태그를 지정하면 선택의 예측 가능성을 높일 수 있습니다.

secondary vs secondaryPreferred

특정 전용 쿼리의 경우(예 ETL, 보고), secondary 읽기 설정 모드를 사용하여 프라이머리에서 읽기 로드를 이동할 수 있습니다. 이 사용 사례에서는 secondary 모드가 secondaryPreferred 모드보다 선호됩니다. secondaryPreferred는 모든 세컨더리를 사용할 수 없고 복제본 세트에 프라이머리가 물러나는 것을 방지할 수 있는 충분한 중재자[3]가 있는 경우, 프라이머리가 클라이언트의 모든 트래픽을 수신하게 되는상황이 발생할 위험이 있기 때문입니다. 프라이머리가 이 로드를 처리할 수 없는 경우 쿼리는 쓰기와 경쟁하게 됩니다. 따라서 읽기 설정 secondary를 사용하여 secondaryPreferred 대신 이러한 특정 전용 쿼리를 배포합니다.