readConcern

이 페이지의 내용

읽기 고려 수준

readConcern Support
고려 사항

readConcern 옵션을 사용하면 복제본 세트와 샤딩된 클러스터에서 읽은 데이터의 일관성 및 격리 속성을 제어할 수 있습니다.

쓰기 고려 사항과 읽기 고려 사항을 효과적으로 사용하여 일관성 및 가용성 보장 수준을 적절히 조정할 수 있습니다(예: 더 강력한 일관성 보장을 기다리거나 일관성 요구 사항을 완화하여 더 높은 가용성을 제공하는 등).

복제본 세트 및 샤드 클러스터는 글로벌 기본 읽기 우려 사항 설정을 지원합니다. 명시적인 읽기 고려를 지정하지 않은 작업에는 글로벌 기본 읽기 고려 설정이 적용됩니다. 자세한 내용은 setDefaultRWConcern을 참조하세요.

읽기 고려 수준

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

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

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

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

`readConcern` Support

읽기 고려 옵션

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

readConcern: { level: <level> }

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

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

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

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

중요

개별 작업에서는 읽기 고려를 명시적으로 설정하면 안 됩니다. 트랜잭션에 대한 읽기 관심사를 설정하려면 읽기 고려/쓰기 고려/읽기 설정을 참조하세요.

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

다중 문서 트랜잭션에서는 다음과 같은 읽기 고려 수준을 사용할 수 있습니다.
다중 문서 트랜잭션의 일부인 쓰기 명령은 트랜잭션 수준의 읽기 고려를 지원할 수 있습니다.
트랜잭션 내에서 컬렉션과 인덱스를 생성할 수 있습니다. 컬렉션 또는 인덱스를 명시적으로 생성하는 경우 트랜잭션은 읽기 고려 "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 4.4 or greater)	✓
`createIndexes` `db.collection.createIndex()` `db.collection.createIndexes()` (Requires FCV 4.4 or greater)	✓

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

`local` 데이터베이스의 경우 읽기 고려 지원 안 됨

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

고려 사항

자체 쓰기 읽기

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

실시간 주문 처리

"linearizable" 읽기 고려를 "majority" 쓰기 고려와 결합해 사용하면 마치 하나의 스레드가 실시간으로 복수의 작업을 실행하는 것처럼 여러 스레드가 복수의 읽기 작업과 쓰기 작업을 실행하도록 허용합니다. 그래서 이러한 읽기와 쓰기에 해당하는 일정이 선형화 가능한 것으로 간주됩니다.

성능 비교

"majority"와는 달리, "linearizable" 읽기 고려는 세컨더리 멤버에 읽기 작업이 { w: "majority" } 쓰기 고려로 쓰기를 확인할 수 있는 프라이머리로부터 읽기를 실행하고 있음을 확인해 줍니다. [4] 따라서 선형화 가능한 읽기 고려가 설정된 읽기가 "majority" 또는 "local" 읽기 고려보다 훨씬 느릴 수 있습니다.

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

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

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는 인과적으로 일관적인 세션에 대한 지원을 포함합니다. 인과적으로 일관적인 세션과 관련된 읽기 작업의 경우, MongoDB는 인과적으로 일관적인 세션과 관련된 작업에서 드라이버가 자동으로 afterClusterTime 읽기 고려 옵션을 설정하도록 지원합니다.

중요

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

참고

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

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

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

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

우려 사항 출처 읽기

MongoDB는 특정 읽기 고려의 원인을 나타내는 읽기 고려 provenance를 추적합니다. provenance는 getLastError 지표, 읽기 고려 오류 객체, MongoDB 로그에 표시됩니다.

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

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

돌아가기

GeoJSON 객체

'로컬'