readConcern

readConcern 옵션을 사용하여 복제본 세트 및 샤딩된 클러스터에서 읽은 데이터의 일관성과 격리를 제어합니다.

쓰기 고려 (write concern) 와 읽기 고려 (read concern)를 효과적으로 사용하여 일관성 및 가용성 보장 수준을 조정할 수 있습니다. 예시 를 들어, 더 강력한 일관성 보장 기다리거나 더 높은 가용성을 위해 일관성 요구 사항을 완화할 수 있습니다.

복제본 세트와 샤딩된 클러스터는 전역 기본값 읽기 고려 (read concern) 지원 . 명시적인 읽기 고려 (read concern) 없는 작업은 전역 기본값 상속합니다. 자세한 내용은 setDefaultRWConcern 를 참조하세요.

읽기 고려 수준

다음과 같은 읽기 고려 수준을 사용할 수 있습니다.

`level`	설명
`"local"`	쿼리 데이터가 대부분의 복제본 세트 멤버에 기록되었다는 보장 없이 인스턴스 에서 데이터를 반환합니다. 데이터가 롤백될 수 있습니다. 기본값은 프라이머리 및 세컨더리에 대한 읽기입니다. 가용성: 읽기 고려 `"local"` 는 인과적으로 일관적인 세션과 트랜잭션의 유무에 관계없이 사용할 수 있습니다. 자세한 내용은 `"local"` 도움말 페이지를 참조하세요.
`"available"`	쿼리 데이터가 대부분의 복제본 세트 멤버에 기록되었다는 보장 없이 인스턴스 에서 데이터를 반환합니다. 데이터가 롤백될 수 있습니다. 가용성: 읽기 고려 `"available"`는 인과적 일관성 세션 및 트랜잭션과 함께 사용할 수 없습니다. 샤딩된 클러스터의 경우, `"available"` 읽기 고려는 다양한 읽기 고려 설정 중에서 읽기 지연 시간이 가장 짧습니다. 하지만 이 방법을 사용하면 `"available"` 읽기 고려가 샤드 컬렉션으로부터 읽기를 실행할 때 고아 문서를 반환할 수 있기 때문에 일관성이 희생됩니다. 샤드 컬렉션에서 읽기를 실행할 때 고아 문서가 반환되는 위험을 피하려면 `"local"` 읽기 고려과 같은 다른 유형의 읽기 고려를 사용하세요. 자세한 내용은 `"available"` 도움말 페이지를 참조하세요.
`"majority"`	쿼리 대부분의 복제본 세트 멤버가 승인한 데이터를 반환합니다. 반환된 문서는 오류가 발생하더라도 지속형 있습니다. 읽기 고려 (read concern) `"majority"`를 해결하기 위해 복제본 세트 멤버는 과반수 커밋 점 의 메모리 내 뷰에서 데이터를 반환합니다. 읽기 고려 (read concern) `"majority"` 의 성능은 다른 읽기 고려와 비슷합니다. 가용성: 읽기 고려 `"majority"` 는 인과적으로 일관적인 세션과 트랜잭션의 유무에 관계없이 사용할 수 있습니다. 요구 사항: 복제본 세트는 WiredTiger 스토리지 엔진사용해야 합니다. For 다중 문서 트랜잭션의 경우, 읽기 고려 (read concern) `"majority"` 는 트랜잭션 쓰기 고려 (write concern) "majority"로 커밋되는 경우에만 보장을 제공합니다. 그렇지 않으면 `"majority"` 트랜잭션에서 읽은 데이터에 대한 보장을 제공하지 않습니다. 자세한 내용은 `"majority"` 도움말 페이지를 참조하세요.
`"linearizable"`	이 쿼리 읽기 작업이 시작되기 전에 완료된 모든 성공적인 과반수 승인 쓰기를 반영하는 데이터를 반환합니다. 쿼리 결과를 반환하기 전에 동시 쓰기가 대다수의 복제본 세트 멤버에 전파될 때까지 기다릴 수 있습니다. 읽기 작업 후 대부분의 복제본 세트 멤버가 충돌했다가 다시 시작되는 경우, `writeConcernMajorityJournalDefault` 가 기본값 인 `true`로 설정하다 있으면 반환된 문서는 지속형 입니다. `writeConcernMajorityJournalDefault`를 `false`로 설정하면 MongoDB는 `w: "majority"` 쓰기가 디스크 저널에 작성되는 것을 기다리지 않고 쓰기를 확인합니다. 따라서 주어진 복제본 세트의 노드 과반수 이상이 일시적으로 손실된 경우(충돌, 재시작 등), `"majority"` 쓰기 작업이 롤백될 가능성이 있습니다. 가용성: 읽기 고려 `"linearizable"`는 인과적으로 일관적인 세션 및 트랜잭션과 함께 사용할 수 없습니다. `primary`의 읽기 작업에 대해서만 선형화 가능한 읽기 고려 (read concern) 지정할 수 있습니다. `$out` 또는 `$merge` 단계는 읽기 고려 `"linearizable"`과 함께 사용할 수 없습니다. 즉, `db.collection.aggregate()`에 `"linearizable"` 읽기 고려를 지정하면 파이프라인에 둘 중 그 어떤 단계도 포함할 수 없습니다. 요구 사항: 선형화 가능 읽기 고려는 읽기 작업이 단일 문서를 고유하게 식별하는 쿼리 필터를 명시하는 경우에만 적용됩니다. 또한 다음 기준 중 어느 하나라도 충족되지 않으면 선형화 가능 읽기 고려가 일관적인 스냅샷에서 읽히지 않아 필터와 일치하는 문서가 반환되지 않을 수 있습니다. 이 쿼리는 변경 불가능한 필드를 쿼리의 검색 키로 사용합니다. 예를 들면 `_id` 필드에서 검색하거나 `$natural`을 사용합니다. 동시 업데이트는 쿼리의 검색 키를 변경하지 않습니다. 검색 키에는 고유 인덱스가 있고 쿼리는 해당 인덱스를 사용합니다. 위의 기준 중 하나라도 충족되면 쿼리는 일관적인 스냅샷을 읽어 일치하는 문서 하나를 반환합니다. 대부분의 데이터 보유 멤버를 사용할 수 없는 경우 항상 선형화 가능한 읽기 고려 (read concern) 와 함께 `maxTimeMS` 를 사용합니다. `maxTimeMS` 는 읽기 고려 (read concern) 충족할 수 없는 경우 무기한 차단하는 대신 작업이 오류를 반환하도록 합니다. 자세한 내용은 `"linearizable"` 도움말 페이지를 참조하세요.
`"snapshot"`	읽기 고려 `"snapshot"`가 설정된 쿼리는 최근에 있었던 특정 단일 시점에 샤드 전체에 표시된 과반수 이상이 커밋한 데이터를 반환합니다. 읽기 고려 `"snapshot"`는 트랜잭션이 쓰기 고려 `"majority"`로 커밋되는 경우에만 보장을 제공합니다. If a transaction is not part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data. If a transaction is part of a causally consistent session, upon transaction commit with write concern `"majority"`, the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start. 가용성: 읽기 고려 `"snapshot"` 을(를) 다음에 사용할 수 있습니다. 다중 문서 트랜잭션 내부의 모든 읽기 작업으로, 트랜잭션 수준에서 읽기 고려 (read concern) 설정하다 . 다중 문서 트랜잭션 외부의 다음과 같은 메서드: `find` `aggregate` `distinct` 샤딩되지 않은 컬렉션에서만 다른 모든 읽기 작업은 `"snapshot"`을 금지합니다.

읽기 고려 수준에 관계없이 노드의 최신 데이터는 시스템에 있는 데이터의 최신 버전을 반영하지 않을 수 있습니다.

각 읽기 고려 수준에 관한 자세한 내용은 다음에서 확인하세요.

`readConcern` Support

읽기 고려 옵션

다중 문서 트랜잭션에서 실행되지 않는 작업의 경우, readConcern 수준을 읽기 고려를 지원하는 명령과 메서드에 대한 옵션으로 지정할 수 있습니다.

readConcern: { level: <level> }

mongosh 메서드에 db.collection.find()에 대한 읽기 고려 수준을 지정하려면 cursor.readConcern() 메서드를 사용합니다.

db.collection.find().readConcern(<level>)

트랜잭션 및 사용 가능한 읽기 고려

다중 문서 트랜잭션의 경우 개별 작업 수준이 아닌 트랜잭션 수준에서 읽기 고려 (read concern) 를 설정하다 . 트랜잭션 작업은 트랜잭션 수준 읽기 고려 (read concern) 사용합니다. 컬렉션 및 데이터베이스 수준에서 설정된 읽기 고려 (read concern)는 트랜잭션 내에서 무시됩니다. 트랜잭션 수준 읽기 고려 (read concern) 명시적으로 설정하다 하면 클라이언트 수준 읽기 고려 (read concern) 도 무시됩니다.

중요

개별 작업에 대한 읽기 고려 (read concern) 명시적으로 설정하다 하지 마세요. 트랜잭션에 대한 읽기 고려 (read concern) 를 설정하다 하려면 읽기 고려, 쓰기 고려 및 읽기 설정을 참조하세요.

트랜잭션 시작 시 읽기 고려를 설정할 수 있습니다.

다중 문서 트랜잭션은 다음과 같은 읽기 고려 (read concern) 수준을 지원 .
다중 문서 트랜잭션의 일부인 쓰기 명령은 트랜잭션 수준의 읽기 고려를 지원할 수 있습니다.
트랜잭션 내에서 컬렉션과 인덱스를 생성할 수 있습니다. 컬렉션 또는 인덱스를 명시적으로 생성하는 경우 트랜잭션은 읽기 고려 "local"을 사용해야 합니다. 컬렉션을 암시적으로 생성하는 경우 트랜잭션에 사용 가능한 읽기 고려를 사용할 수 있습니다.

트랜잭션 시작 시 수준이 지정되지 않은 경우 트랜잭션은 세션 수준의 읽기 고려를 사용하고, 이것이 설정되지 않은 경우에는 클라이언트 수준의 읽기 고려를 사용합니다.

자세한 내용은 트랜잭션 읽기 고려를 참조하세요.

인과적으로 일관적인 세션 및 사용 가능한 읽기 고려

인과적으로 일관적인 세션에서 수행되는 작업의 경우,"local" "majority"및 수준을 사용할 수 "snapshot" 있습니다. 인과적 일관성 보장하려면 "majority"를 사용합니다. 자세한 내용은 인과적 일관성참조하세요.

읽기 고려를 지원하는 작업

다음 작업은 읽기 고려를 지원합니다.

중요

트랜잭션 내 작업에 읽기 고려를 설정하려면 개별 작업 수준이 아닌 트랜잭션 수준에서 읽기 고려를 설정하세요. 트랜잭션 내 개별 작업에는 읽기 고려를 명시적으로 설정하면 안 됩니다. 자세한 내용은 거래 및 우려 사항 읽기를 참조하십시오.

명령/메서드	`"local"`	`"available"`	`"majority"`	`"snapshot"` [3]	`"linearizable"`
`count`	✓	✓	✓		✓
`distinct`	✓	✓	✓	✓ [2]	✓
`find`	✓	✓	✓	✓	✓
`db.collection.find()` 통해 `cursor.readConcern()`	✓	✓	✓	✓	✓
`getMore`	✓				✓
`aggregate` `db.collection.aggregate()`	✓	✓	✓	✓	✓ [3]
`Session.startTransaction()`	✓		✓	✓

[1]	`$out` 또는 `$merge` 단계는 읽기 고려 `"linearizable"`과 함께 사용할 수 없습니다. 즉, `db.collection.aggregate()`에 `"linearizable"` 읽기 고려를 지정하면 파이프라인에 둘 중 그 어떤 단계도 포함할 수 없습니다.

[2]	읽기 고려 `"snapshot"`은 특정 읽기 작업 및 다중 문서 트랜잭션에만 사용할 수 있습니다. 트랜잭션에서는 샤드 컬렉션에 `distinct` 명령이나 헬퍼를 사용할 수 없습니다.

또한, 다음 쓰기 작업은 다중 문서 트랜잭션의 일부인 경우 읽기 고려를 수락할 수 있습니다.

중요

트랜잭션 내 작업에 읽기 고려를 설정하려면 개별 작업 수준이 아닌 트랜잭션 수준에서 읽기 고려를 설정하세요.

명령	`"local"`	`"snapshot"` [3]
`delete` `db.collection.deleteOne()` `db.collection.deleteMany()` `db.collection.remove()`	✓	✓
`findAndModify` `db.collection.findAndModify()` `db.collection.findOneAndDelete()` `db.collection.findOneAndReplace()` `db.collection.findOneAndUpdate()`	✓	✓
`insert` `db.collection.insertOne()` `db.collection.insertMany()`	✓	✓
`update` `db.collection.updateOne()` `db.collection.updateMany()` `db.collection.replaceOne()`	✓	✓
`create` `db.createCollection()` (Requires FCV 6.0 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires FCV 6.0 or greater)	✓

[3]	(1, 2) 읽기 고려 (read concern) `"snapshot"` 는 특정 읽기 작업 및 다중 문서 트랜잭션에만 사용할 수 있습니다. 트랜잭션의 경우 트랜잭션 수준에서 읽기 고려 (read concern) 를 설정하다 . `"snapshot"` 를 지원 트랜잭션 작업은 트랜잭션에서 사용할 수 있는 CRUD 작업에 해당합니다. 자세한 내용은 트랜잭션 및 읽기 고려 (read concern)를 참조하세요.

`local` 데이터베이스에서 읽기 고려 (read concern)가 지원되지 않음

로컬 데이터베이스 읽기 고려 (read concern)를 지원 하지 않습니다. MongoDB 로컬 데이터베이스 의 컬렉션에 대한 작업에 대해 구성된 읽기 고려 (read concern) 자동으로 무시합니다.

고려 사항

자체 쓰기 읽기

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

실시간 주문 처리

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

성능 비교

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

대부분의 데이터 보유 멤버를 사용할 수 없는 경우 항상 선형화 가능한 읽기 고려 (read concern) 와 함께 maxTimeMS 를 사용합니다. maxTimeMS 는 읽기 고려 (read concern) 충족할 수 없는 경우 무기한 차단하는 대신 작업이 오류를 반환하도록 합니다.

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

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

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

읽기 작업 및 `afterClusterTime`

MongoDB 인과적으로 일관적인 세션을 지원합니다. 인과적으로 일관적인 세션에서 읽기 작업을 수행하는 경우 드라이버는 afterClusterTime 읽기 고려 (read concern) 옵션을 자동으로 설정하다 .

중요

읽기 작업에 대해 afterClusterTime 을 수동으로 설정하다 하지 마세요. MongoDB 드라이버는 인과적으로 일관적인 세션에서 수행되는 작업에 대해 이 값을 자동으로 설정하다 . 그러나 다른 클라이언트 세션의 작업과 일관적인 하도록 세션의 작업 시간과 클러스터 시간을 앞당길 수 있습니다. 예시 보려면 예시를 참조하세요.

참고

atClusterTime 은 afterClusterTime와 함께 지정할 수 없습니다. 읽기 고려 (read concern) "snapshot"와 함께 atClusterTime 을 사용하려면 인과적으로 일관적인 세션을 비활성화합니다.

afterClusterTime 값이 T인 읽기 요청을 충족하려면 mongod 가 oplog 시간 T에 도달한 후 요청을 수행해야 합니다. oplog 시간 T에 도달하지 않은 경우 mongod 는 요청 처리하기 위해 대기합니다.

지정된 afterClusterTime 가 있는 읽기 작업은 읽기 고려 (read concern) 사항 과 지정된 afterClusterTime 요구 사항을 모두 충족하는 데이터를 반환합니다.

인과적으로 일관적인 세션과 관련이 없는 읽기 작업의 경우 afterClusterTime이 설정되지 않습니다.

우려 사항 출처 읽기

MongoDB 읽기 고려 (read concern) 의 소스를 나타내는 읽기 고려 (read concern) provenance를 추적합니다. provenance 값은 getLastError 지표, 읽기 고려 (read concern) 오류 객체 및 MongoDB 로그에 표시됩니다.

다음 표는 가능한 읽기 provenance 고려 의 값과 그 중요성을 보여줍니다.

출처	설명
`clientSupplied`	읽기 우려 사항은 애플리케이션에서 지정되었습니다.
`customDefault`	읽기 고려가 사용자가 정의한 기본값에서 발생했습니다. `setDefaultRWConcern`을 참조하세요.
`implicitDefault`	다른 모든 읽기 고려 사양이 부재해 서버에서 읽기 고려가 발생했습니다.

돌아가기

GeoJSON 객체

'로컬'