readConcern

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

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

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

읽기 고려 수준

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

`level`	설명
`"local"`	쿼리 데이터가 대부분의 복제본 세트 멤버에 기록되었다는 보장 없이 인스턴스 에서 데이터를 반환합니다. 데이터가 롤백될 수 있습니다. 기본값은 프라이머리 및 세컨더리에 대한 읽기입니다. 가용성: 읽기 고려 는 인과적으로 일관적인 세션과 트랜잭션의 유무에 관계없이 사용할 수 `"local"` 있습니다. 자세한 내용은 `"local"` 도움말 페이지를 참조하세요.
`"available"`	쿼리 데이터가 대부분의 복제본 세트 멤버에 기록되었다는 보장 없이 인스턴스 에서 데이터를 반환합니다. 데이터가 롤백될 수 있습니다. 가용성: 읽기 고려 `"available"`는 인과적 일관성 세션 및 트랜잭션과 함께 사용할 수 없습니다. 샤딩된 클러스터의 경우, `"available"` 읽기 고려는 다양한 읽기 고려 설정 중에서 읽기 지연 시간이 가장 짧습니다. 하지만 이 방법을 사용하면 `"available"` 읽기 고려가 샤드 컬렉션으로부터 읽기를 실행할 때 고아 문서를 반환할 수 있기 때문에 일관성이 희생됩니다. 샤드 컬렉션에서 읽기를 실행할 때 고아 문서가 반환되는 위험을 피하려면 `"local"` 읽기 고려과 같은 다른 유형의 읽기 고려를 사용하세요. 자세한 내용은 `"available"` 도움말 페이지를 참조하세요.
`"majority"`	쿼리 대부분의 복제본 세트 멤버가 승인한 데이터를 반환합니다. 반환된 문서는 오류가 발생하더라도 지속형 있습니다. 읽기 고려 (read concern) `"majority"` 를 해결하기 위해 복제본 세트 멤버는 과반수 커밋 점 의 메모리 내 뷰에서 데이터를 반환합니다. 읽기 고려 의 성능은 다른 읽기 고려와 `"majority"` 비슷합니다. 가용성: 읽기 고려 는 인과적으로 일관적인 세션과 트랜잭션의 유무에 관계없이 사용할 수 `"majority"` 있습니다. 요구 사항: 복제본 세트는 WiredTiger 스토리지 엔진 사용해야 합니다. 다중 문서 트랜잭션의 경우, 읽기 고려 (read concern) 는 트랜잭션 쓰기 고려 `"majority"` (write concern) "majority"로 커밋되는 경우에만 보장 을 제공합니다. 그렇지 않으면`"majority"` 트랜잭션에서 읽은 데이터에 대한 보장 제공하지 않습니다. 자세한 내용은 `"majority"` 도움말 페이지를 참조하세요.
`"linearizable"`	이 쿼리 읽기 작업이 시작되기 전에 완료된 모든 성공적인 과반수 승인 쓰기를 반영하는 데이터를 반환합니다. 쿼리 결과를 반환하기 전에 동시 쓰기가 대다수의 복제본 세트 멤버에 전파될 때까지 기다릴 수 있습니다. 읽기 작업 후 대부분의 복제본 세트 멤버가 충돌했다가 다시 시작되는 경우,`writeConcernMajorityJournalDefault` 가 기본값 인 로 설정하다 있으면 반환된 문서는 지속형 `true` 입니다. `writeConcernMajorityJournalDefault`를 `false`로 설정하면 MongoDB는 `w: "majority"` 쓰기가 디스크 저널에 작성되는 것을 기다리지 않고 쓰기를 확인합니다. 따라서 주어진 복제본 세트의 노드 과반수 이상이 일시적으로 손실된 경우(충돌, 재시작 등), `"majority"` 쓰기 작업이 롤백될 가능성이 있습니다. 가용성: 읽기 고려 `"linearizable"`는 인과적으로 일관적인 세션 및 트랜잭션과 함께 사용할 수 없습니다. 의 읽기 작업에 대해서만 선형화 가능한 읽기 고려 (read concern) 지정할 수 `primary` 있습니다. `$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) 수준을 지원 .
다중 문서 트랜잭션의 일부인 쓰기 명령은 트랜잭션 수준의 읽기 고려를 지원할 수 있습니다.
트랜잭션 내에서 컬렉션과 인덱스를 생성할 수 있습니다. 컬렉션 또는 인덱스를 명시적으로 생성하는 경우 트랜잭션은 읽기 고려 "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) 읽기 고려 `"snapshot"` 는 특정 읽기 작업 및 다중 문서 트랜잭션에만 사용할 수 있습니다. 트랜잭션의 경우 트랜잭션 수준에서 읽기 고려 (read concern) 를 설정하다 . 를 지원 트랜잭션 작업은 트랜잭션에서 사용할 수 `"snapshot"` 있는 CRUD 작업에 해당합니다. 자세한 내용은 트랜잭션 및 읽기 고려를 참조하세요.

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

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

고려 사항

자체 쓰기 읽기

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

실시간 주문 처리

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

성능 비교

와(과) "majority" 달리"linearizable" 읽기 고려 (read concern) 세컨더리 멤버에 읽기 작업이 쓰기 고려 (write concern) 통해 쓰기를 확인할 { w: "majority" } 수 있는 프라이머리 에서 읽는다는 것을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) 옵션을 자동으로 설정하다 .

중요

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

참고

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

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

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

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

우려 사항 출처 읽기

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

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

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

돌아가기

GeoJSON 객체

'로컬'