트랜잭션 (Transactions)

트랜잭션 (Transactions)

MongoDB에서 단일 문서에 대한 연산은 원자적(atomic)입니다. 여러 문서와 컬렉션에 걸쳐 정규화하는 대신 임베디드 문서와 배열을 이용해 단일 문서 구조 안에서 데이터 사이의 관계를 표현할 수 있기 때문에, 실제 많은 사용 사례에서는 다중 문서 트랜잭션(multi-document transaction)이 꼭 필요하지 않습니다.

여러 문서에 걸친 연산의 원자성이 필요한 상황이라면 MongoDB는 트랜잭션을 지원합니다. 트랜잭션은 여러 연산·컬렉션·데이터베이스·문서·샤드에 걸쳐 사용할 수 있습니다.

트랜잭션 API (Transactions API)

언어 선택기를 사용해 아래 예시의 언어를 설정할 수 있습니다.

이 예시는 트랜잭션 API의 핵심 구성 요소를 보여줍니다. 특히 콜백 API(callback API)를 사용하는데, 콜백 API는 다음을 수행합니다:

  • 트랜잭션을 시작하고
  • 지정된 연산을 실행한 뒤
  • 결과를 커밋하거나, 오류 발생 시 트랜잭션을 종료합니다.

DuplicateKeyError 같은 서버 측 연산 오류는 트랜잭션을 종료시키고, 트랜잭션이 종료되었음을 알려주는 커맨드 오류를 발생시킬 수 있습니다. 이 동작은 클라이언트가 Session.abortTransaction()을 호출하지 않더라도 예상대로 발생합니다. 사용자 정의 오류 처리를 추가하려면 트랜잭션에 Core API를 사용하세요.

콜백 API는 특정 오류에 대한 재시도 로직을 포함합니다. 드라이버는 TransientTransactionError 또는 UnknownTransactionCommitResult 커밋 오류 이후 트랜잭션을 다시 실행하려고 시도합니다.

MongoDB 6.2부터 서버는 TransactionTooLargeForCache 오류를 받으면 트랜잭션을 재시도하지 않습니다.

MongoDB 8.1부터 다중 문서 트랜잭션에서 upsert 연산이 중복 키 오류(duplicate key error)를 만나면 해당 upsert는 재시도되지 않습니다.

중요:

아래는 트랜잭션 API의 핵심 요소를 보여주는 Python 드라이버 예시입니다. (다른 언어 드라이버도 동일한 콜백 API 패턴을 따릅니다.)

# For a replica set, include the replica set name and a seedlist of the members in the URI string; e.g.
# uriString = 'mongodb://mongodb0.example.com:27017,mongodb1.example.com:27017/?replicaSet=myRepl'
# For a sharded cluster, connect to the mongos instances; e.g.
# uriString = 'mongodb://mongos0.example.com:27017,mongos1.example.com:27017/'

client = MongoClient(uriString)
wc_majority = WriteConcern("majority", wtimeout=1000)

# Prereq: Create collections.
client.get_database("mydb1", write_concern=wc_majority).foo.insert_one({"abc": 0})
client.get_database("mydb2", write_concern=wc_majority).bar.insert_one({"xyz": 0})

# Step 1: Define the callback that specifies the sequence of operations to perform inside the transactions.
def callback(session):
    collection_one = session.client.mydb1.foo
    collection_two = session.client.mydb2.bar

    # Important: You must pass the session to the operations.
    collection_one.insert_one({"abc": 1}, session=session)
    collection_two.insert_one({"xyz": 999}, session=session)

# Step 2: Start a client session.
with client.start_session() as session:
    # Step 3: Use with_transaction to start a transaction, execute the callback, and commit (or abort on error).
    session.with_transaction(callback)

참고: 각 드라이버 언어(Python, Java, JavaScript, PHP, C#, C, C++, Ruby, Rust, Go, Scala 등)에 대한 전체 예시는 공식 MongoDB 트랜잭션 문서와 드라이버별 문서를 참고하세요.

참고: mongosh 예시는 mongosh Example을 참고하세요.

트랜잭션과 원자성 (Transactions and Atomicity)

여러 문서(단일 또는 여러 컬렉션)에 대한 읽기·쓰기의 원자성이 필요한 상황이라면 MongoDB는 분산 트랜잭션(distributed transactions)을 지원합니다. 여기에는 레플리카 셋과 샤드 클러스터에서의 트랜잭션이 모두 포함됩니다.

분산 트랜잭션은 원자적입니다:

  • 트랜잭션은 모든 데이터 변경을 적용하거나, 변경을 모두 롤백합니다.
  • 트랜잭션이 커밋되면 트랜잭션에서 이루어진 모든 데이터 변경이 저장되고 트랜잭션 외부에서도 보입니다.
    • 트랜잭션이 커밋되기 전까지 트랜잭션 내부에서 이루어진 데이터 변경은 트랜잭션 외부에서 보이지 않습니다.
    • 다만 트랜잭션이 여러 샤드에 쓸 때, 커밋된 트랜잭션의 결과가 모든 샤드에 걸쳐 보이기까지 외부 읽기 연산이 모두 기다릴 필요는 없습니다. 예를 들어 트랜잭션이 커밋되어 쓰기 1이 샤드 A에 보이지만 쓰기 2가 아직 샤드 B에 보이지 않을 때, read concern "local"인 외부 읽기는 쓰기 2를 보지 않고 쓰기 1의 결과만 읽을 수 있습니다.
  • 트랜잭션이 중단(abort)되면 트랜잭션에서 이루어진 모든 데이터 변경은 한 번도 보이지 않은 채 폐기됩니다.

중요:

대부분의 경우 분산 트랜잭션은 단일 문서 쓰기보다 성능 비용이 더 크며, 분산 트랜잭션의 가용성이 효과적인 스키마 설계를 대체해서는 안 됩니다. 많은 시나리오에서 비정규화된 데이터 모델(임베디드 문서와 배열)이 데이터와 사용 사례에 여전히 최적입니다. 즉 많은 시나리오에서 데이터를 적절히 모델링하면 분산 트랜잭션의 필요성을 최소화할 수 있습니다.

추가적인 트랜잭션 사용 고려 사항(런타임 한도, oplog 크기 한도 등)은 Production Considerations를 참고하세요.

참고: 커밋 중 외부 읽기 (Outside Reads During Commit)

트랜잭션과 연산 (Transactions and Operations)

트랜잭션은 여러 연산·컬렉션·데이터베이스·문서·샤드에 걸쳐 사용할 수 있습니다.

트랜잭션과 관련하여:

  • 트랜잭션에서 컬렉션과 인덱스를 생성할 수 있습니다. 자세한 내용은 트랜잭션에서 컬렉션과 인덱스 생성을 참고하세요.
  • 트랜잭션에서 사용하는 컬렉션은 서로 다른 데이터베이스에 있을 수 있습니다.
    • 참고: 크로스 샤드 쓰기 트랜잭션(cross-shard write transaction)에서는 새 컬렉션을 생성할 수 없습니다. 예를 들어 한 샤드의 기존 컬렉션에 쓰면서 다른 샤드에 컬렉션을 암시적으로 생성하는 경우, MongoDB는 두 연산을 같은 트랜잭션에서 수행할 수 없습니다.
  • capped 컬렉션에 쓸 수 없습니다.
  • capped 컬렉션에서 읽을 때 read concern "snapshot"을 사용할 수 없습니다. (MongoDB 5.0부터)
  • config, admin, local 데이터베이스의 컬렉션을 읽거나 쓸 수 없습니다.
  • system.* 컬렉션에 쓸 수 없습니다.
  • explain 또는 유사한 명령으로 지원되는 연산의 쿼리 플랜을 반환할 수 없습니다.
  • 트랜잭션 밖에서 생성된 커서에 대해 트랜잭션 안에서 getMore를 호출할 수 없습니다.
  • 트랜잭션 안에서 생성된 커서에 대해 트랜잭션 밖에서 getMore를 호출할 수 없습니다.
  • killCursors 명령을 트랜잭션의 첫 번째 연산으로 지정할 수 없습니다.
    • 또한 트랜잭션 안에서 killCursors 명령을 실행하면 서버는 지정된 커서를 즉시 중지합니다. 트랜잭션이 커밋될 때까지 기다리지 않습니다.

트랜잭션에서 지원되지 않는 연산 목록은 Restricted Operations를 참고하세요.

팁:

트랜잭션을 시작하기 직전에 컬렉션을 생성하거나 삭제할 때, 그 컬렉션을 트랜잭션 안에서 접근한다면 트랜잭션이 필요한 잠금을 획득할 수 있도록 해당 create/drop 연산을 write concern "majority"로 실행하세요.

참고: 트랜잭션과 연산 참조 (Transactions and Operations Reference)

트랜잭션에서 컬렉션과 인덱스 생성 (Create Collections and Indexes in a Transaction)

크로스 샤드 쓰기 트랜잭션이 아니라면 트랜잭션 안에서 다음 연산을 수행할 수 있습니다:

  • 컬렉션 생성
  • 같은 트랜잭션에서 앞서 만든 새 빈 컬렉션에 인덱스 생성

트랜잭션 안에서 컬렉션을 만들 때:

트랜잭션 안에서 인덱스를 생성할 때, 생성할 인덱스는 다음 중 하나에 있어야 합니다:

  • 존재하지 않는 컬렉션. 이 경우 컬렉션은 해당 연산의 일부로 생성됩니다.
  • 같은 트랜잭션에서 앞서 만든 새 빈 컬렉션.

또한 기존 인덱스에 대해 db.collection.createIndex()와 db.collection.createIndexes()를 실행해 존재 여부를 확인할 수 있습니다. 이 연산들은 인덱스를 생성하지 않고 성공을 반환합니다.

제한 사항 (Restrictions)

  • 크로스 샤드 쓰기 트랜잭션에서는 새 컬렉션을 생성할 수 없습니다. 예를 들어 한 샤드의 기존 컬렉션에 쓰면서 다른 샤드에 컬렉션을 암시적으로 생성하는 경우, MongoDB는 두 연산을 같은 트랜잭션에서 수행할 수 없습니다.
  • 샤드 컬렉션을 대상으로 하는 트랜잭션 안에서는 $graphLookup 단계를 사용할 수 없습니다.
  • 트랜잭션 안에서 컬렉션이나 인덱스를 명시적으로 생성하려면 트랜잭션 read concern 레벨이 "local"이어야 합니다.
    • 컬렉션과 인덱스를 명시적으로 생성하려면 다음 명령과 메서드를 사용합니다:
명령 메서드
create db.createCollection()
createIndexes db.collection.createIndex(), db.collection.createIndexes()

참고: Restricted Operations

Count 연산 (Count Operation)

트랜잭션 안에서 count 연산을 수행하려면 $count 집계 단계 또는 (설명을 포함한) $sum이 포함된 $group 집계 단계를 사용하세요.

MongoDB 드라이버는 $group과 $sum 표현식으로 count를 수행하는 컬렉션 레벨 API 헬퍼 메서드 countDocuments(filter, options)를 제공합니다.

mongosh는 $group과 $sum 표현식으로 count를 수행하는 db.collection.countDocuments() 헬퍼 메서드를 제공합니다.

Distinct 연산 (Distinct Operation)

트랜잭션 안에서 distinct 연산을 수행하려면:

  • 샤드되지 않은 컬렉션에서는 db.collection.distinct() 메서드/distinct 명령뿐 아니라 $group 단계가 포함된 집계 파이프라인도 사용할 수 있습니다.
  • 샤드 컬렉션에서는 db.collection.distinct() 메서드와 distinct 명령을 사용할 수 없습니다.

    • 샤드 컬렉션의 distinct 값을 찾으려면 대신 $group 단계가 포함된 집계 파이프라인을 사용하세요. 예를 들어:

    • db.coll.distinct("x") 대신:

      db.coll.aggregate([
   { $group: { _id: null, distinctValues: { $addToSet: "$x" } } },
   { $project: { _id: 0 } }
])

    • db.coll.distinct("x", { status: "A" }) 대신:

      db.coll.aggregate([
   { $match: { status: "A" } },
   { $group: { _id: null, distinctValues: { $addToSet: "$x" } } },
   { $project: { _id: 0 } }
])

    • 파이프라인은 문서에 대한 커서를 반환합니다:

      { "distinctValues" : [ 2, 3, 1 ] }

    • 커서를 반복해 결과 문서에 접근합니다.

정보성 연산 (Informational Operations)

hello, buildInfo, connectionStatus 같은 정보성 명령(및 그 헬퍼 메서드)은 트랜잭션에서 허용되지만, 트랜잭션의 첫 번째 연산이 될 수는 없습니다.

제한 연산 (Restricted Operations)

다음 연산은 트랜잭션에서 허용되지 않습니다:

  • 크로스 샤드 쓰기 트랜잭션에서 새 컬렉션 생성. 예를 들어 한 샤드의 기존 컬렉션에 쓰면서 다른 샤드에 컬렉션을 암시적으로 생성하는 경우, MongoDB는 두 연산을 같은 트랜잭션에서 수행할 수 없습니다.
  • read concern 레벨이 "local"이 아닌 경우의 컬렉션 명시적 생성(예: db.createCollection() 메서드)과 인덱스 생성(예: db.collection.createIndexes(), db.collection.createIndex() 메서드).
  • listCollections와 listIndexes 명령 및 그 헬퍼 메서드.
  • 기타 비-CRUD·비-정보성 연산. 예를 들어 createUser, getParameter, count 등과 그 헬퍼.
  • 병렬 연산(Parallel operations). 여러 네임스페이스를 동시에 업데이트하려면 대신 bulkWrite 명령을 사용하는 것을 고려하세요.

참고:

트랜잭션과 세션 (Transactions and Sessions)

  • 트랜잭션은 세션(session)과 연결됩니다.
  • 세션당 한 번에 최대 하나의 열린 트랜잭션을 가질 수 있습니다.
  • 드라이버를 사용할 때 트랜잭션의 각 연산은 그 세션과 연결되어야 합니다. 자세한 내용은 드라이버별 문서를 참고하세요.
  • 세션이 끝나고 열린 트랜잭션이 있다면 트랜잭션은 중단됩니다.

Read Concern, Write Concern, Read Preference

트랜잭션과 Read Preference

트랜잭션의 연산은 트랜잭션 레벨 read preference를 사용합니다.

드라이버를 사용하면 트랜잭션 시작 시 트랜잭션 레벨 read preference를 설정할 수 있습니다:

  • 트랜잭션 레벨 read preference가 설정되지 않으면 트랜잭션은 세션 레벨 read preference를 사용합니다.
  • 트랜잭션 레벨과 세션 레벨 read preference가 모두 설정되지 않으면 트랜잭션은 클라이언트 레벨 read preference를 사용합니다. 기본적으로 클라이언트 레벨 read preference는 primary입니다.

읽기 연산을 포함하는 트랜잭션은 read preference primary를 사용해야 합니다. 주어진 트랜잭션의 모든 연산은 같은 멤버로 라우팅되어야 합니다.

트랜잭션과 Read Concern

트랜잭션의 연산은 트랜잭션 레벨 read concern을 사용합니다. 즉 컬렉션·데이터베이스 레벨에서 설정된 read concern은 트랜잭션 안에서 무시됩니다.

트랜잭션 시작 시 트랜잭션 레벨 read concern을 설정할 수 있습니다.

  • 트랜잭션 레벨 read concern이 설정되지 않으면 트랜잭션 레벨 read concern은 기본적으로 세션 레벨 read concern을 따릅니다.
  • 트랜잭션 레벨과 세션 레벨 read concern이 모두 설정되지 않으면 트랜잭션 레벨 read concern은 기본적으로 클라이언트 레벨 read concern을 따릅니다. 기본적으로 primary에서 읽는 경우 클라이언트 레벨 read concern은 "local"입니다. 다음도 참고하세요:

트랜잭션은 다음 read concern 레벨을 지원합니다:

"local"

  • Read concern "local"은 노드에서 사용할 수 있는 가장 최근 데이터를 반환하지만 롤백될 수 있습니다.
  • 레플리카 셋에서 트랜잭션이 read concern local을 사용하더라도, 트랜잭션이 열린 시점의 스냅샷에서 읽어 더 강한 읽기 격리를 관찰할 수 있습니다.
  • 샤드 클러스터의 트랜잭션에서 "local" read concern은 데이터가 샤드 전반에서 같은 스냅샷 뷰에서 온 것임을 보장할 수 없습니다. 스냅샷 격리가 필요하면 "snapshot" read concern을 사용하세요.
  • 트랜잭션 안에서 컬렉션과 인덱스를 생성할 수 있습니다. 컬렉션이나 인덱스를 명시적으로 생성한다면 트랜잭션은 read concern "local"을 사용해야 합니다. 암시적으로 컬렉션을 생성한다면 트랜잭션에 사용 가능한 어떤 read concern이든 사용할 수 있습니다.

"majority"

  • 트랜잭션이 write concern majority로 커밋되면 read concern "majority"는 레플리카 셋 멤버의 과반이 승인했고 롤백될 수 없는 데이터를 반환합니다. 그렇지 않으면 read concern "majority"는 읽기 연산이 majority-committed 데이터를 읽는다는 보장을 제공하지 않습니다.
  • 샤드 클러스터의 트랜잭션에서 read concern "majority"는 데이터가 샤드 전반에서 같은 스냅샷 뷰에서 온 것임을 보장할 수 없습니다. 스냅샷 격리가 필요하면 read concern "snapshot"을 사용하세요.

"snapshot"

  • Read concern "snapshot"은 트랜잭션이 write concern majority로 커밋될 경우에만 majority-committed 데이터의 스냅샷에서 데이터를 반환합니다.
  • 트랜잭션이 커밋에 write concern majority를 사용하지 않으면 "snapshot" read concern은 읽기 연산이 majority-committed 데이터의 스냅샷을 사용했다는 보장을 제공하지 않습니다.
  • 샤드 클러스터의 트랜잭션에서 "snapshot" 데이터 뷰는 샤드 전반에서 동기화됩니다.

트랜잭션과 Write Concern

트랜잭션은 쓰기 연산을 커밋할 때 트랜잭션 레벨 write concern을 사용합니다. 트랜잭션 안의 쓰기 연산은 명시적인 write concern 지정 없이 실행되어야 하며 기본 write concern을 사용해야 합니다. 커밋 시점에 쓰기는 트랜잭션 레벨 write concern으로 커밋됩니다.

팁:

트랜잭션 안에서 개별 쓰기 연산에 write concern을 명시적으로 설정하지 마세요. 트랜잭션 안의 개별 쓰기 연산에 write concern을 설정하면 오류가 반환됩니다.

트랜잭션 시작 시 트랜잭션 레벨 write concern을 설정할 수 있습니다:

  • 트랜잭션 레벨 write concern이 설정되지 않으면 커밋 시 트랜잭션 레벨 write concern은 기본적으로 세션 레벨 write concern을 따릅니다.
  • 트랜잭션 레벨과 세션 레벨 write concern이 모두 설정되지 않으면 트랜잭션 레벨 write concern은 기본적으로 다음 클라이언트 레벨 write concern을 따릅니다:

참고: MongoDB 기본값 (MongoDB Defaults)

트랜잭션은 다음을 포함한 모든 write concern w 값을 지원합니다:

w: 1

  • Write concern w: 1은 커밋이 primary에 적용된 후 승인을 반환합니다.
  • write concern w: 1로 커밋하면 트랜잭션 레벨 "majority" read concern은 트랜잭션의 읽기 연산이 majority-committed 데이터를 읽는다는 보장을 제공하지 않습니다.
  • write concern w: 1로 커밋하면 트랜잭션 레벨 "snapshot" read concern은 트랜잭션의 읽기 연산이 majority-committed 데이터의 스냅샷을 사용했다는 보장을 제공하지 않습니다.

w: "majority"

  • Write concern w: "majority"은 커밋이 투표 멤버 과반에 적용된 후 승인을 반환합니다.
  • write concern w: "majority"로 커밋하면 트랜잭션 레벨 "majority" read concern은 연산이 majority-committed 데이터를 읽었음을 보장합니다. 샤드 클러스터의 트랜잭션에서 이 majority-committed 데이터 뷰는 샤드 전반에 동기화되지 않습니다.
  • write concern w: "majority"로 커밋하면 트랜잭션 레벨 "snapshot" read concern은 연산이 majority-committed 데이터의 동기화된 스냅샷에서 읽었음을 보장합니다.

참고:

트랜잭션에 지정된 write concern에 관계없이, 샤드 클러스터 트랜잭션의 커밋 연산에는 {w: "majority", j: true} write concern을 사용하는 일부 부분이 포함됩니다.

서버 매개변수 coordinateCommitReturnImmediatelyAfterPersistingDecision은 트랜잭션 커밋 결정이 클라이언트에 반환되는 시점을 제어합니다. 이 매개변수는 MongoDB 5.0에서 기본값 true로 도입되었고, MongoDB 6.1에서 기본값이 false로 변경됩니다.

coordinateCommitReturnImmediatelyAfterPersistingDecision가 false이면 샤드 트랜잭션 코디네이터는 커밋 결정을 클라이언트에 반환하기 전에 모든 멤버가 트랜잭션 커밋을 승인할 때까지 기다립니다.

쓰기에 write concern "majority"를 지정했는데 응답을 반환하기 전에 연산이 계산된 과반의 레플리카 셋 멤버로 복제되지 않으면, 데이터는 결국 복제되거나 롤백됩니다. wtimeout을 참고하세요.

트랜잭션에 지정된 write concern에 관계없이, 드라이버는 commitTransaction을 재시도할 때 write concern으로 w: "majority"를 적용합니다.

트랜잭션 고려 사항 (Transactions Considerations)

다음 섹션에서는 배포 유형, 스토리지 엔진, MongoDB 버전에 따라 달라지는 트랜잭션 요구 사항과 고려 사항을 설명합니다.

Production Considerations

프로덕션 환경의 트랜잭션은 Production Considerations를 참고하세요. 또한 샤드 클러스터의 경우 Production Considerations (Sharded Clusters)를 참고하세요.

Arbiters

arbiter는 데이터를 포함하지 않는 투표용 레플리카이므로, MongoDB는 데이터를 보호하고 여러 샤드에 걸친 데이터 트랜잭션([트랜잭션으로 샤드 키 변경하는 것 포함)이 arbiter를 포함한 레플리카 셋의 샤드를 대상으로 하지 못하도록 막습니다.

트랜잭션의 어떤 연산이 arbiter를 포함한 샤드를 읽거나 쓰더라도, MongoDB는 여러 샤드에 걸쳐 쓰는 트랜잭션을 차단합니다.

샤드 구성 제한 (Shard Configuration Restriction)

샤드 클러스터에서 트랜잭션을 실행하려면 writeConcernMajorityJournalDefault가 true로 설정되어야 합니다.

참고:

트랜잭션에 지정된 write concern에 관계없이, 샤드 클러스터 트랜잭션의 커밋 연산에는 {w: "majority", j: true} write concern을 사용하는 일부 부분이 포함됩니다.

진단 (Diagnostics)

트랜잭션 상태와 지표를 얻으려면 다음 메서드를 사용하세요:

출처 반환값
db.serverStatus() 메서드, serverStatus 명령 transactions 지표를 반환합니다. 일부 serverStatus 응답 필드는 MongoDB Atlas Free 클러스터 또는 Flex 클러스터에서 반환되지 않습니다. 자세한 내용은 MongoDB Atlas 문서의 Limited Commands를 참고하세요.
$currentOp 집계 파이프라인 연산이 트랜잭션의 일부이면 $currentOp.transaction을 반환합니다. 여러 샤드에 쓰는 샤드 트랜잭션에 대한 $currentOp.twoPhaseCommitCoordinator 지표도 반환합니다. 트랜잭션의 일부로 잠금을 보유한 비활성 세션 정보도 포함합니다.
db.currentOp() 메서드, currentOp 명령 연산이 트랜잭션의 일부이면 currentOp.transaction을 반환합니다. 여러 샤드에 쓰는 샤드 트랜잭션에 대한 currentOp.twoPhaseCommitCoordinator 지표도 반환합니다.
mongod 및 mongos 로그 메시지 TXN 로그 컴포넌트에서 느린 트랜잭션(즉 operationProfiling.slowOpThresholdMs 임계값을 초과하는 트랜잭션) 정보를 포함합니다.

Feature Compatibility Version (FCV)

트랜잭션을 사용하려면 배포의 모든 멤버의 featureCompatibilityVersion이 최소한 다음과 같아야 합니다:

배포 최소 featureCompatibilityVersion
레플리카 셋 4.0
샤드 클러스터 4.2

멤버의 FCV를 확인하려면 해당 멤버에 연결하고 다음 명령을 실행하세요:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

자세한 내용은 setFeatureCompatibilityVersion 참조 페이지를 참고하세요.

스토리지 엔진 (Storage Engines)

트랜잭션은 다음 조건을 만족하는 레플리카 셋과 샤드 클러스터에서 지원됩니다:

  • primary가 WiredTiger 스토리지 엔진을 사용하고,
  • secondary 멤버가 WiredTiger 스토리지 엔진 또는 in-memory 스토리지 엔진을 사용하는 경우.

참고:

in-memory 스토리지 엔진을 사용하는 투표 멤버가 있어 writeConcernMajorityJournalDefault가 false로 설정된 샤드가 있는 샤드 클러스터에서는 트랜잭션을 실행할 수 없습니다.

임계 섹션 대기 시간 제한 (Limit Critical Section Wait Time)

MongoDB 5.2(및 5.0.4)부터:

  • 쿼리가 샤드에 접근할 때, 청크 마이그레이션(chunk migration) 또는 DDL 연산이 컬렉션의 임계 섹션을 보유할 수 있습니다.
  • 트랜잭션 내에서 샤드가 임계 섹션을 기다리는 시간을 제한하려면 metadataRefreshInTransactionMaxWaitMS 매개변수를 사용하세요.
    • 참고: MongoDB 8.1부터 기존 metadataRefreshInTransactionMaxWaitBehindCritSecMS 매개변수는 metadataRefreshInTransactionMaxWaitMS로 이름이 변경되었습니다. metadataRefreshInTransactionMaxWaitBehindCritSecMS를 계속 매개변수 이름으로 사용할 수 있지만, 이는 deprecated이며 향후 MongoDB 릴리스에서 제거될 예정입니다.

더 알아보기 (Learn More)