readConcern `"linearizable"`

"linearizable"

이 쿼리는 읽기 작업이 시작되기 전에 완료되고 과반수 이상이 확인한 모든 성공적인 쓰기를 반영하는 데이터를 반환합니다. 쿼리는 결과를 반환하기 전에 동시에 실행 중인 쓰기가 복제본 세트 구성원의 과반수에 전파될 때까지 기다릴 수 있습니다.

읽기 고려 후 과반수의 복제본 세트 멤버가 충돌했다가 다시 시작되는 경우, writeConcernMajorityJournalDefault가 기본 상태인 true로 설정되어 있으면 읽기 고려에서 반환된 문서가 지속됩니다.

writeConcernMajorityJournalDefault를 false로 설정하면 MongoDB는 w: "majority" 쓰기가 디스크 저널에 작성되는 것을 기다리지 않고 쓰기를 확인합니다. 따라서 주어진 복제본 세트의 노드 과반수 이상이 일시적으로 손실된 경우(충돌, 재시작 등), "majority" 쓰기 작업이 롤백될 가능성이 있습니다.

읽기 작업에 선형화 가능한 읽기 고려를 지정하는 것은 primary에서만 가능합니다.

선형화된 읽기 고려는 읽기 작업이 단일 문서를 고유하게 식별하는 쿼리 필터를 명시하는 경우에만 적용됩니다.

팁

데이터를 가진 멤버의 과반수 이상을 사용할 수 없는 경우, 항상 선형화 가능한 읽기 고려와 함께 maxTimeMS를 사용하세요. maxTimeMS는 작업이 무기한으로 차단되지 않도록 하며, 대신 읽기 고려를 충족할 수 없는 경우 작업이 오류를 반환하도록 합니다.

인과적으로 일관된 세션

읽기 고려 "linearizable" 는 인과적으로 일관적인 세션에서 사용할 수 없습니다.

집계 제한

또는 단계는 읽기 고려 와 함께 $out $merge 사용할 "linearizable" 수 없습니다. 즉,"linearizable" 에 읽기 고려를 지정하면 파이프라인에 두 단계를 모두 포함할 수 없습니다.db.collection.aggregate()

실시간 주문 처리

"majority" 쓰기 고려와 결합된 "linearizable" 읽기 고려를 사용하면 단일 스레드가 실시간으로 이러한 작업을 수행하는 것처럼 여러 스레드가 단일 문서에 대한 읽기 및 쓰기를 수행할 수 있습니다. 즉, 이러한 읽기 및 쓰기에 해당하는 일정은 선형화 가능한 것으로 간주됩니다.

자체 쓰기 읽기

버전 3.6에서 변경됨.

MongoDB 3.6부터는 쓰기에서 승인을 요청하는 경우 인과적으로 일관된 세션을 사용하여 자신의 쓰기를 읽을 수 있습니다.

MongoDB 3 이전 버전.6, 자신의 쓰기를 읽으려면 { w: "majority" } 쓰기 고려로 쓰기 작업을 실행한 다음 primary 읽기 설정과 "majority" 또는 "linearizable" 읽기 고려를 사용하여 읽기 작업을 실행해야 합니다.

성능 비교

"majority" 과 달리 { "linearizable" 읽기 고려는 세컨더리 멤버에 읽기 작업이 { w: "majority" } 쓰기 고려로 쓰기를 확인할 수 있는 프라이머리에서 읽고 있음을 확인합니다. [1] 따라서 선형화 가능한 읽기 고려를 가진 읽기는 "majority" 또는 "local" 읽기 고려를 가진 읽기보다 훨씬 느릴 수 있습니다.

예를 들면 다음과 같습니다.

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )

[1] 일부 상황에서는 복제본 세트의 두 노드가 일시적으로 자신이 주 노드라고 생각할 수 있지만, { w: "majority" }개의 쓰기 우려로 쓰기를 완료할 수 있는 노드는 최대 한 개뿐입니다. { w: "majority" }개의 쓰기를 완료할 수 있는 노드가 현재의 주 노드이고, 다른 노드는 보통 네트워크 파티션으로 인해 강등된 것을 아직 인식하지 못한 이전의 주 노드입니다. 이 경우 이전 주 노드에 연결한 클라이언트는 읽기 기본 설정 primary를 요청했음에도 불구하고 오래된 데이터를 보게 되며, 이전의 주 노드에 대한 새로운 쓰기는 결국 롤백됩니다.

← readConcern "majority"

readConcern "snapshot" →