읽기 설정
읽기 설정은 MongoDB 클라이언트가 복제본 세트 노드에 읽기 작업을 어떻게 라우팅하는지 설명합니다.
기본적으로 애플리케이션은 읽기 작업을 복제본 집합의 프라이머리 멤버로 지시합니다. (즉, 읽기 기본 설정 모드 "primary"). 그러나 클라이언트는 읽기 설정을 지정하여 읽기 작업을 세컨더리 멤버로 보낼 수 있습니다.
읽기 기본 설정은 읽기 설정 모드와 선택적으로 태그 세트 목록 및 maxStalenessSeconds 옵션으로 구성됩니다.
읽기 설정 모드
다음 표에는 읽기 설정 모드가 요약되어 있습니다.
읽기 설정 모드 | 설명 |
---|---|
모든 작업은 복제본 세트의 세컨더리 멤버에서 읽습니다. | |
작업은 지정된 지연 시간 임계값에 따라 프라이머리 멤버든 세컨더리 멤버든 상관없이 임의의 적격 복제본 세트 멤버에서 읽습니다. 이 작업은 지연 시간을 계산할 때 다음 사항을 고려합니다.
|
읽기 환경설정 모드에 대한 자세한 설명은 읽기 설정 모드를 참조하세요.
행동
primary
제외한 모든 읽기 설정 모드는 오래된 데이터를 반환할 수 있습니다. 이는 세컨더리가 프라이머리로부터 작업을 비동기적으로 복제하기 때문입니다. [1]primary
가 아닌 모드를 사용하기로 결정했다면, 애플리케이션이 오래된 데이터를 허용할 수 있는지 확인하세요.읽기 기본 설정은 데이터의 가시성에 영향을 주지 않습니다. 즉, 클라이언트는 쓰기 결과가 확인되거나 대다수의 복제본 세트 노드에 전파되기 전에 쓰기 결과를 볼 수 있습니다. 자세한 내용은 격리, 일관성 및 최신성(Recency) 읽기를 참조하세요.
읽기 설정은 인과적 일관성에 영향을 미치지 않습니다.
"majority"
읽기 고려가 있는 읽기 작업과"majority"
쓰기 고려가 쓰기 작업에 대해 인과적으로 일관성이 있는 세션을 제공하는 인과적 일관성 보장은 MongoDB deployment의 모든 멤버에 걸쳐 유지됩니다.
경고
마이그레이션이 있는 샤딩된 클러스터의 세컨더리 읽기는 문서를 놓칠 수 있습니다.
샤딩된 클러스터에서 장기 실행 세컨더리 읽기는 마이그레이션이 발생하는 경우 문서를 누락할 수 있습니다.
청크 마이그레이션 중에 청크를 삭제하기 전에, MongoDB는 orphanCleanupDelaySecs
또는 청크와 관련된 진행 중인 쿼리가 샤드 프라이머리에서 완료될 때까지 둘 중 더 긴 시간을 기다립니다. 처음에 프라이머리 노드에서 실행되었지만 노드가 세컨더리 노드로 내려간 후에도 계속되는 쿼리는 처음에 세컨더리 노드에서 실행된 것처럼 처리됩니다. 즉, 서버는 현재 기본 서버에 청크를 대상으로 하는 쿼리가 없는 경우에만 orphanDelayCleanupSecs
동안 대기합니다.
청크를 대상으로 하고 세컨더리에서 실행되는 쿼리는 쿼리가 orphanCleanupDelaySecs
보다 오래 걸리면 문서를 누락할 수 있습니다.
읽기 설정 모드
primary
모든 읽기 작업은 현재 복제본 세트의 프라이머리만 사용합니다. [1] 기본 읽기 모드입니다. 만약 프라이머리가 사용할 수 없는 경우 읽기 작업에서 오류가 발생하거나 예외가 발생합니다.
primary
읽기 설정 모드는 태그 세트 목록이나 maxStalenessSeconds를 사용하는 읽기 설정 모드와 호환되지 않습니다. 태그 세트 목록 또는maxStalenessSeconds
값을primary
로 지정하면 드라이버에서 오류를 생성합니다.읽기 작업이 포함된 분산 트랜잭션은 읽기 설정(read preference)
primary
를 사용해야 합니다. 특정 트랜잭션의 모든 작업은 동일한 노드로 라우팅되어야 합니다.
primaryPreferred
대부분의 경우 작업은 세트의 프라이머리 멤버에서 읽습니다. 그러나 페일오버 조치 상황과 같이 프라이머리 멤버를 사용할 수 없는 경우에는 읽기 설정의
maxStalenessSeconds
및 태그 세트 목록을 충족하는 세컨더리 멤버로부터 작업을 읽습니다.primaryPreferred
읽기 설정에 maxStalenessSeconds 값이 포함되어 있고 읽어올 프라이머리가 없는 경우, 클라이언트는 세컨더리의 마지막 쓰기를 가장 최근 쓰기가 있는 세컨더리의 마지막 쓰기와 비교하여 각 세컨더리가 얼마나 오래 되었는지 추정합니다. 그런 다음 클라이언트는 예상 지연이maxStalenessSeconds
이하인 세컨더리에 읽기 작업을 지시합니다.읽기 설정에 태그 세트 목록 (태그 세트의 배열)이 포함되어 있고 읽을 수 있는 프라이머리 멤버가 없는 경우, 클라이언트는 일치하는 태그가 있는 세컨더리 멤버를 찾으려고 시도합니다 (일치하는 태그가 발견될 때까지 태그 세트를 차례로 시도합니다). 일치하는 세컨더리 멤버가 발견되면 클라이언트는 일치하는 세컨더리 멤버의 가장 가까운 그룹에서 무작위로 세컨더리를 선택합니다. 일치하는 태그를 가진 세컨더리 멤버가 없는 경우, 읽기 작업은 오류를 발생시킵니다.
읽기 기본 설정에
maxStalenessSeconds
값 과 태그 세트 목록이 포함되어 있는 경우, 클라이언트는 먼저 오래된 정도에 따라 필터링한 다음 지정된 태그를 기준으로 필터링합니다.primaryPreferred
모드를 사용한 읽기 작업은 오래된 데이터를 반환할 수 있습니다.maxStalenessSeconds
옵션을 사용하면 클라이언트가 너무 오래되었다고 추정하는 세컨더리에서 데이터를 읽지 않도록 할 수 있습니다.
secondary
작업은 세트의 오직 세컨더리로부터만 읽습니다.사용 가능한 세컨더리 멤버가 없으면 이 읽기 작업에서 오류나 예외가 발생합니다.
대부분의 복제본 세트에는 최소한 하나의 세컨더리가 있지만 사용 가능한 세컨더리가 없는 상황도 있습니다.예를 들어 하나의 프라이머리, 하나의 세컨더리, 그리고 하나의 중재자가 있는 복제본 세트에서 멤버가 복구 중이거나 사용할 수 없는 경우 세컨더리 멤버가 없을 수 있습니다.
secondary
읽기 설정에 maxStalenessSeconds 값이 포함된 경우 클라이언트는 세컨더리의 마지막 쓰기를 프라이머리의 마지막 쓰기와 비교하여 각 세컨더리의 부실 정도를 추정합니다. 그런 다음 클라이언트는 예상 지연이maxStalenessSeconds
이하인 세컨더리에 읽기 작업을 지시합니다. 프라이머리가 없으면 클라이언트는 비교를 위해 가장 최근에 쓴 세컨더리를 사용합니다.읽기 설정에 태그 세트 목록 (태그 세트의 배열)이 포함된 경우 클라이언트는 일치하는 태그가 있는 세컨더리 구성원을 찾으려고 시도합니다 (일치하는 태그가 발견될 때까지 태그 세트을 순서대로 시도). 일치하는 세컨더리가 발견되면 클라이언트는 일치하는 세컨더리 멤버 중 가장 가까운 그룹에서 무작위로 세컨더리를 선택합니다. 일치하는 태그를 가진 세컨터리 멤버가 없는 경우, 읽기 작업은 오류를 발생시킵니다.
읽기 기본 설정에
maxStalenessSeconds
값 과 태그 세트 목록이 포함되어 있는 경우, 클라이언트는 먼저 오래된 정도에 따라 필터링한 다음 지정된 태그를 기준으로 필터링합니다.secondary
모드를 사용한 읽기 작업은 오래된 데이터를 반환할 수 있습니다.maxStalenessSeconds
옵션을 사용하면 클라이언트가 너무 오래되었다고 추정하는 세컨더리에서 데이터를 읽지 않도록 할 수 있습니다.
secondaryPreferred
작업은 일반적으로 복제본 세트의 세컨더리 노드에서 데이터를 읽습니다. 만약 복제본 세트에 프라이머리 노드가 하나만 있고 다른 노드가 없다면, 작업은 프라이머리 노드에서 데이터를 읽습니다.
secondaryPreferred
읽기 설정(read preference)에 maxStalenessSeconds 값이 포함된 경우 클라이언트는 세컨더리의 마지막 쓰기를 프라이머리의 마지막 쓰기와 비교하여 각 세컨더리의 부실 정도를 추정합니다. 그런 다음 클라이언트는 예상 지연이maxStalenessSeconds
이하인 세컨더리에 읽기 작업을 지시합니다. 프라이머리가 없으면 클라이언트는 비교를 위해 가장 최근에 쓴 세컨더리를 사용합니다. 예상 지연 시간이maxStalenessSeconds
이하인 세컨더리가 없는 경우 클라이언트는 읽기 작업을 복제본 세트의 프라이머리로 보냅니다.읽기 환경 설정에 태그 세트 목록(태그 세트의 배열)이 포함된 경우 클라이언트는 일치하는 태그가 있는 세컨더리 멤버를 찾으려고 시도합니다(일치하는 태그가 발견될 때까지 태그 세트을 순서대로 시도). 일치하는 세컨더리가 발견되면 클라이언트는 일치하는 세컨더리의 가장 가까운 그룹에서 무작위로 세컨더리를 선택합니다. 일치하는 태그를 가진 세컨더리가 없는 경우, 클라이언트는 태그를 무시하고 프라이머리에서 읽습니다.
읽기 기본 설정에
maxStalenessSeconds
값 과 태그 세트 목록이 포함되어 있는 경우, 클라이언트는 먼저 오래된 정도에 따라 필터링한 다음 지정된 태그를 기준으로 필터링합니다.secondaryPreferred
모드를 사용한 읽기 작업은 오래된 데이터를 반환할 수 있습니다.maxStalenessSeconds
옵션을 사용하면 클라이언트가 너무 오래되었다고 추정하는 세컨더리에서 데이터를 읽지 않도록 할 수 있습니다.
nearest
드라이버는 네트워크 지연이 허용 가능한 대기 시간 창 내에 속하는 멤버로부터 읽습니다.
nearest
모드에서의 읽기는 읽기 작업을 라우팅할 때 멤버가 프라이머리 멤버인지 세컨더리 멤버인지를 고려하지 않습니다. 프라이머리 멤버와 세컨더리 멤버는 동등하게 취급됩니다.이 모드를 설정하면 현재 데이터나 오래된 데이터를 선호하지 않고 네트워크 지연 시간이 읽기 작업에 미치는 영향을 최소화할 수 있습니다.
읽기 설정에 MaxStalenessSeconds 값이 포함된 경우 가능하다면 클라이언트는 세컨더리의 마지막 쓰기를 프라이머리의 마지막 쓰기 작업과 비교하고, 프라이머리가 없는 경우 가장 최근에 쓴 세컨더리와 비교하여 각 세컨더리가 얼마나 오래 되었는지 추정합니다. 그런 다음 클라이언트는 예상 지연이
maxStalenessSeconds
보다 큰 세컨더리를 필터링하고 네트워크 지연이 허용 가능한 지연 시간 내에 있는 나머지 멤버 (프라이머리 또는 세컨더리)에게 무작위로 읽기를 지시합니다.태그 세트 목록을 지정하면 클라이언트는 지정된 태그 세트 목록과 일치하는 복제본 세트 멤버을 찾으려고 시도하고, 가장 가까운 그룹 중에서 임의의 멤버에게 읽기를 지시합니다.
읽기 설정에
maxStalenessSeconds
값과 태그 세트 목록이 포함되어 있는 경우 클라이언트는 먼저 오래된 정도에 따라 필터링한 다음 지정된 태그를 기준으로 필터링합니다. 나머지mongod
인스턴스에서 클라이언트는 허용 가능한 지연 시간 범위 내에 있는 인스턴스로 읽기를 임의로 지시합니다. 읽기 설정 멤버 선택 문서에 이 프로세스에 대한 자세한 설명이 나와 있습니다.nearest
모드를 사용한 읽기 작업은 오래된 데이터를 반환할 수 있습니다.maxStalenessSeconds
옵션을 사용하면 클라이언트가 너무 오래되었다고 추정하는 세컨더리에서 데이터를 읽지 않도록 할 수 있습니다.
읽기 환경설정 구성
MongoDB 드라이버를 사용하는 경우 드라이버의 읽기 설정 API를 사용하여 읽기 설정을 지정할 수 있습니다. 자세한 내용은 드라이버 API 문서를 참조하세요. 복제본 세트 또는 샤딩된 클러스터에 연결할 때 읽기 기본 설정을 지정할 수도 있습니다. 예시는 연결 문자열에서 확인할 수 있습니다.
주어진 읽기 설정에 대해 MongoDB 드라이버는 동일한 노드 선택 로직을 사용합니다.
mongosh
사용 시 cursor.readPref()
및 Mongo.setReadPref()
를 참조합니다.
읽기 환경설정 및 트랜젝션
읽기 작업이 포함된 분산 트랜잭션은 읽기 설정(read preference) primary
를 사용해야 합니다. 특정 트랜잭션의 모든 작업은 동일한 노드로 라우팅되어야 합니다.
추가 고려 사항
집계 파이프라인에서 $merge
또는 $out
단계를 사용할 때는 다음 사항을 고려하세요.
MongoDB 5.0부터
$merge
단계가 있는 파이프라인은 클러스터의 모든 노드에서 featureCompatibilityVersion이5.0
이상으로 설정되어 있고 읽기 설정이 세컨더리 읽기를 허용하는 경우 복제본 세트 세컨더리 노드에서 실행될 수 있습니다.이전 MongoDB 버전에서는
$out
또는$merge
단계가 있는 파이프라인은 항상 기본 노드에서 실행되며 읽기 기본 설정은 고려되지 않았습니다.
mapReduce
작업의 경우 mapReduce
데이터를 쓰지 않는 "inline" 작업만 읽기 설정을 지원합니다. 그렇지 않으면 mapReduce
작업은 프라이머리 멤버에서 실행됩니다.
[1] | (1, 2) 경우에 따라 복제본 세트의 두 노드가 일시적으로 자신이 프라이머리 노드라고 생각할 수 있지만 이 중 최대 하나만 { w:
"majority" } 쓰기 고려로 쓰기를 완료 수 있습니다. { w: "majority" } 쓰기를 완료할 수 있는 노드가 현재 프라이머리 노드이고 다른 노드는 일반적으로 네트워크 파티션으로 인해 아직 강등을 인식하지 못한 이전 프라이머리 노드입니다. 이 경우 이전 프라이머리 노드에 연결하는 클라이언트는 읽기 설정 primary 를 요청했음에도 불구하고 오래된 데이터를 볼 수 있으며 이전 프라이머리 노드에 대한 새로운 쓰기는 결국 롤백됩니다. |