llm-wiki/raw/official-docs/read-concern-mongodb-official.md

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title	source_type	url	archive_url	status	confidence	tags	related_projects	related_branches	created	last_reviewed
official-doc / MongoDB — Read Concern (Levels & Guarantees)	official-doc	https://www.mongodb.com/docs/manual/reference/read-concern/		raw	high	official-doc ca-skeleton persistence mongodb consistent-read	ca-skeleton	feature-mongo-runtime-baseline-contract	2026-07-28	2026-07-28

official-doc / MongoDB — Read Concern (Levels & Guarantees)

Layer: raw/official-docs/ — MongoDB 공식 Manual reference (read-concern) 원문 발췌. feature-mongo-runtime-baseline-contract 의 "MongoDB 조회는 read concern 을 명시하고 기본값에 의존하지 않는다" 결정 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-mongo-runtime-baseline-contract	MongoDB 조회는 read concern 을 명시하고 기본값에 의존하지 않는다 — local/available/majority/linearizable/snapshot 5개 level 이 각각 무엇을 보장/비보증하는지, majority 가 replica-set·multi-document transaction 과 맺는 관계, level 별 topology·operation 제약(예: linearizable 은 primary 전용, snapshot 은 트랜잭션 밖에서 find/aggregate/distinct(unsharded 전용)로만 제한)의 verbatim 근거

컨텍스트

ca-skeleton 은 MongoDB 를 optional adapter(문서 저장소 축)로 채택할 수 있다. 본 branch 는 조회(read) 시 read concern 을 애플리케이션/드라이버 레벨에서 명시할지, 서버 implicit default 에 의존할지를 결정해야 한다. 이 판단에는 (1) 5개 level 각각이 어떤 데이터를 반환하고 무엇을 보증/비보증하는지, (2) majority read concern 이 multi-document transaction 안에서 write concern 과 맺는 관계, (3) 각 level 이 어떤 topology(standalone/replica set/sharded cluster)·operation 에서만 쓸 수 있는지에 대한 공식 정의가 필요하다.

출처 / Source

• 원본 URL: https://www.mongodb.com/docs/manual/reference/read-concern/
• 아카이브 URL: (미수집)
• 저자 / 조직: MongoDB, Inc.
• 발행일: MongoDB Manual (현재 버전 — level별 상세 하위 페이지 read-concern-local/read-concern-available/read-concern-majority/read-concern-linearizable/read-concern-snapshot 를 링크하는 최신 manual 구조로 판단)
• 마지막 확인일: 2026-07-28

핵심 인용 / Key quotes (verbatim)

[§read-concern-local / §read-concern-available — 두 level 이 동일 문장을 공유] "The query returns data from the instance with no guarantee that the data has been written to a majority of the replica set members. Data may be rolled back."

[§read-concern-local] "Default for reads against the primary and secondaries."

[§read-concern-available] "However, this comes at the expense of consistency as "available" read concern can return orphaned documents when reading from a sharded collection."

[§read-concern-majority] "The query returns the data acknowledged by a majority of the replica set members. Returned documents are durable, even if a failure occurs."

[§read-concern-majority — Requirements] "Replica sets must use the WiredTiger storage engine."

[§read-concern-majority — Transactions] "For multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern "majority"." [...] "Otherwise, "majority" provides no guarantees about data read in transactions."

[§read-concern-linearizable] "You can only specify linearizable read concern for read operations on the primary."

[§read-concern-linearizable] "Linearizable read concern guarantees only apply if read operations specify a query filter that uniquely identifies a single document."

[§read-concern-snapshot] "A query with read concern "snapshot" returns majority-committed data as it appears across shards from a specific single point in time in the recent past."

[§read-concern-snapshot — Transactions] "Read concern "snapshot" provides its guarantees only if the transaction commits with write concern "majority"."

[§read-concern-snapshot — Supported Operations] "The following methods outside of multi-document transactions:" ... "distinct on unsharded collections only"

[§Read Concern and the local Database] "The local database does not support read concerns. MongoDB silently ignores any configured read concern for operations on collections in the local database."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
MONGO-READCONCERN-C1	local read concern 은 인스턴스가 가진 데이터를 반환하며, 그 데이터가 replica set 과반수에 기록되었다는 보장이 없고 rollback 될 수 있다	[§read-concern-local] "The query returns data from the instance with no guarantee that the data has been written to a majority of the replica set members. Data may be rolled back."	official-vendor-doc	local read concern 을 사용하는 primary/secondary read 전반	어느 정도 stale 할 수 있는지(지연 시간)는 이 문장이 규정하지 않음
MONGO-READCONCERN-C2	local 은 primary·secondary 조회 모두에 대해 기본(default) read concern 이다	[§read-concern-local] "Default for reads against the primary and secondaries."	official-vendor-doc	read concern 을 명시하지 않은 모든 조회(단, causally consistent session/transaction 등 다른 기본값이 적용되는 맥락은 제외)	모든 driver/client 설정에서 예외 없이 항상 local 이 적용된다는 것까지는 이 한 문장만으로 보장하지 않음 — 세션/트랜잭션별 기본값은 별도 확인 필요
MONGO-READCONCERN-C3	available read concern 은 sharded collection 조회 시 orphaned document(잘못 라우팅되어 남아있는 document)를 반환할 수 있다	[§read-concern-available] "However, this comes at the expense of consistency as "available" read concern can return orphaned documents when reading from a sharded collection."	official-vendor-doc	available read concern, sharded cluster topology	non-sharded replica set 에서도 동일한 orphaned document 위험이 있다는 뜻은 아님 — orphaned document 는 sharding 특유 현상
MONGO-READCONCERN-C4	majority read concern 은 replica set 과반수에 승인(acknowledge)된 데이터를 반환하며, 실패가 발생해도 반환된 문서는 durable 하다	[§read-concern-majority] "The query returns the data acknowledged by a majority of the replica set members. Returned documents are durable, even if a failure occurs."	official-vendor-doc	majority read concern 을 사용하는 replica set 조회 전반	성능이 다른 level 과 항상 동일하다는 것을 이 문장 자체가 수치로 증명하지는 않음
MONGO-READCONCERN-C5	majority read concern 을 사용하려면 replica set 이 WiredTiger storage engine 을 써야 한다	[§read-concern-majority — Requirements] "Replica sets must use the WiredTiger storage engine."	official-vendor-doc	majority read concern 채택 여부 판단	다른 storage engine 에서 정확히 어떤 에러/폴백이 발생하는지는 이 문장이 설명하지 않음 — "요구사항"만 명시
MONGO-READCONCERN-C6	multi-document transaction 안에서 majority read concern 은 트랜잭션이 write concern "majority" 로 커밋될 때만 보장을 제공하며, 그렇지 않으면 트랜잭션 내에서 읽은 데이터에 대해 어떤 보장도 제공하지 않는다	[§read-concern-majority — Transactions] "For multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern "majority". Otherwise, "majority" provides no guarantees about data read in transactions."	official-vendor-doc	multi-document transaction 내부에서 majority read concern 을 사용하는 모든 read	트랜잭션 밖의 단일 read operation 에서의 majority 보장 여부는 별도(C4 가 이미 커버) — 이 claim 은 트랜잭션 맥락에 한정
MONGO-READCONCERN-C7	linearizable read concern 은 replica set 의 primary 멤버에서 수행하는 read operation 에만 지정할 수 있다	[§read-concern-linearizable] "You can only specify linearizable read concern for read operations on the primary."	official-vendor-doc	linearizable read concern, replica set topology(primary 한정)	sharded cluster 에서 linearizable 사용 가능 여부를 직접 서술하지 않음 — primary member 제약만 명시
MONGO-READCONCERN-C8	linearizable read concern 의 보장은 read operation 이 단일 document 를 고유하게 식별하는 query filter 를 지정할 때만 적용된다	[§read-concern-linearizable] "Linearizable read concern guarantees only apply if read operations specify a query filter that uniquely identifies a single document."	official-vendor-doc	linearizable 을 사용하는 쿼리의 filter 설계	다중 document 대상 쿼리 자체가 문법적으로 금지된다는 뜻은 아님 — "guarantee 가 적용되지 않는다"는 의미로, 실행 자체의 허용 여부와는 구분
MONGO-READCONCERN-C9	snapshot read concern 은 여러 shard 에 걸쳐 특정 단일 시점(recent past)의 majority-committed 데이터를 반환한다	[§read-concern-snapshot] "A query with read concern "snapshot" returns majority-committed data as it appears across shards from a specific single point in time in the recent past."	official-vendor-doc	snapshot read concern, sharded cluster 포함 다중 shard 조회	이 보장이 자동으로 오는 것은 아니며 트랜잭션이 write concern "majority" 로 커밋되어야 함(별도 C10)
MONGO-READCONCERN-C10	snapshot read concern 의 보장은 트랜잭션이 write concern "majority" 로 커밋될 때만 제공된다	[§read-concern-snapshot — Transactions] "Read concern "snapshot" provides its guarantees only if the transaction commits with write concern "majority"."	official-vendor-doc	multi-document transaction 내 snapshot read concern	트랜잭션 밖에서 사용하는 snapshot(find/aggregate/distinct)에도 "트랜잭션 커밋" 조건이 그대로 적용된다는 뜻은 아님 — 트랜잭션 밖 사용은 별도(C11)
MONGO-READCONCERN-C11	multi-document transaction 밖에서 snapshot read concern 을 사용할 수 있는 operation 은 find, aggregate, 그리고 distinct(단, unsharded collection 에서만)로 제한된다	[§read-concern-snapshot — Supported Operations] "The following methods outside of multi-document transactions:" ... "distinct on unsharded collections only"	official-vendor-doc	트랜잭션 없이 단일 operation 에 snapshot read concern 을 지정하는 경우	sharded collection 에서 트랜잭션 밖 distinct + snapshot 조합이 가능한지는 이 문장이 오히려 불가능하다고 증명함(허용이 아니라 제약 근거) — 트랜잭션 내부의 distinct 는 이 제약과 무관(트랜잭션-레벨이므로)
MONGO-READCONCERN-C12	MongoDB 의 local 데이터베이스(리플리케이션 메타데이터 등 내부용 특수 DB)에 대한 operation 은 read concern 을 지원하지 않으며, 어떤 read concern 이 설정되어도 조용히 무시된다	[§Read Concern and the local Database] "The local database does not support read concerns. MongoDB silently ignores any configured read concern for operations on collections in the local database."	official-vendor-doc	이름이 local 인 특수 시스템 데이터베이스 상의 operation	사용자 애플리케이션 데이터가 담긴 일반 database/collection 에서도 read concern 이 무시된다는 뜻이 아님 — 오직 시스템 local DB 에만 해당(read concern level "local" 과는 다른 개념이므로 혼동 주의)

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • MONGO-READCONCERN-C1~C2: local 이 무엇을 (비)보증하는지, 그리고 read 의 implicit default 라는 사실
  • MONGO-READCONCERN-C3: available 이 sharded collection 에서 orphaned document 를 반환할 수 있다는 위험
  • MONGO-READCONCERN-C4~C6: majority 의 정의, WiredTiger 요건, multi-document transaction 내에서의 조건부 보장(write concern "majority" 커밋 필요)
  • MONGO-READCONCERN-C7~C8: linearizable 이 primary 전용이고 단일 document uniquely-identifying filter 를 요구한다는 제약
  • MONGO-READCONCERN-C9~C11: snapshot 의 point-in-time majority-committed 정의, 트랜잭션 write concern "majority" 조건, 트랜잭션 밖 사용 시 operation 제한(find/aggregate/distinct-unsharded-only)
  • MONGO-READCONCERN-C12: 시스템 local 데이터베이스는 read concern 설정 자체를 무시함
• 이 자료가 증명하지 않는 것:
  • 각 level 의 실제 지연시간(latency) 수치 비교 — 상대적 순서(예: linearizable 이 가장 느림)는 원문에 언급되나 이번 raw 에는 verbatim 인용/self-grep 미포함(별도 확인 필요)
  • 드라이버(Java Reactive Streams / Spring Data MongoDB 등)가 read concern 을 어떤 설정 키·API 로 노출하는지 — 이 자료는 서버 개념만 정의
  • causally consistent session 에서의 read concern 조합 세부(예: afterClusterTime 자동 설정 메커니즘) — 이번 raw 수집 범위 밖(추가 확인 필요 항목으로 아래 메모에 기록)
  • readConcern provenance(clientSupplied/customDefault/implicitDefault) 추적 메커니즘의 세부 동작 — 이번 raw 에는 verbatim 미수집
• ca-skeleton 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • ca-skeleton 이 채택할 MongoDB 배포(standalone / replica set / sharded cluster)에 따라 어떤 level 조합이 실제로 유효한지 재확인 — 특히 linearizable(primary 전용)·snapshot(트랜잭션 or 제한된 operation) 은 sharded cluster 여부에 민감
  • majority 채택 시 실제 배포가 WiredTiger 를 쓰는지(현대 MongoDB 배포판은 기본값이나, 별도 storage engine 설정을 쓰지 않는지) 확인
  • Spring Data MongoDB(또는 채택할 드라이버)가 readConcern 을 어떤 설정 키·API 로 노출하는지 — 별도 official-doc 필요 (raw/official-docs/write-concern-mongodb-official.md 와 동일한 드라이버 바인딩 gap)

메모 / Notes

• 본 fetch 는 WebFetch 소형 모델이 markdown 하이퍼링크 문법으로 원문을 재구성한 형태였다. 링크 문법이 문장 중간에 끼어들어 self-grep 리터럴 매칭이 여러 차례 깨졌다(예: "available" read concern can return orphaned documents 사이에 "orphaned documents" 를 감싸는 하이퍼링크가 삽입된 형태). 총 7회의 WebFetch 재요청으로 (1) 하이퍼링크 마크업 제거 + (2) level 이름을 감싸는 큰따옴표("majority" 등, 문서 값 표기의 일부)는 보존하도록 명시적으로 지시해 최종 인용을 확보했다. 원문 페이지 자체의 HTML 은 curl 로 직접 대조하지 않음 — 다음 재검증 시 curl 직접 fetch 로 교차 확인 권장(write-concern-mongodb-official.md 메모와 동일한 한계).
• local/available 두 level 의 기본 정의 문장이 원문에서 완전히 동일하다(WebFetch 3회 반복 확인, 동일 문자열 재현). 두 level 의 실질적 차이는 이 공유 문장이 아니라 (1) available 만 causally consistent session/transaction 에서 사용 불가하고 (2) sharded collection 에서 orphaned document 를 반환할 수 있다는 추가 제약(C3)에 있다.
• 미수집(추가 fetch 필요): causally consistent session 에서 사용 가능한 level 목록 문장("local"/"majority"/"snapshot"), readConcern provenance 3종 값의 세부 동작, level별 상대적 성능 비교 문장(linearizable 이 가장 느림 — best practice 로 maxTimeMS 권장).
• 다음 fetch 후보: MongoDB 공식 causal-consistency(causally consistent session) 페이지, transactions 페이지(read concern 과 write concern 조합 표).

Related / 관련

• 같은 주제 다른 official-doc:
  • raw/official-docs/write-concern-mongodb-official — write concern (w/j/wtimeout) 공식 근거, 같은 branch 의 write 측 대응 문서
  • raw/official-docs/change-streams-mongodb-official — change stream resume token/oplog window
  • raw/official-docs/read-preference-mongodb-official — 조회를 어느 replica set 멤버로 라우팅할지(read concern 과는 별개 축)
  • raw/official-docs/retryable-writes-mongodb-official — write 재시도 공식 근거
  • raw/official-docs/mongodb-connection-string-options — connection string 옵션
• 인용하는 branch: raw/branch-notes/feature-mongo-runtime-baseline-contract
• 인용하는 project: raw/project-notes/ca-skeleton-operational-contract
• 인용한 wiki 요약: (미작성)