프로덕션 고려 사항(샤딩된 클러스터)
You can perform multi-document transactions on sharded clusters.
The following page lists concerns specific to running transactions on a sharded cluster. These concerns are in addition to those listed in 프로덕션 고려 사항.
성능
Single Shard
Transactions that target a single shard should have the same performance as replica-set transactions.
Multiple Shards
Transactions that affect multiple shards incur a greater performance cost.
참고
On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.
Time Limit
To specify a time limit, specify a maxTimeMS
limit on
commitTransaction
.
If maxTimeMS
is unspecified, MongoDB will use the
transactionLifetimeLimitSeconds
.
If maxTimeMS
is specified but would result in transaction that
exceeds transactionLifetimeLimitSeconds
, MongoDB will use
the transactionLifetimeLimitSeconds
.
To modify transactionLifetimeLimitSeconds
for a sharded
cluster, the parameter must be modified for all shard replica set
members.
Read Concerns
Multi-document transactions support "local"
,
"majority"
, and "snapshot"
read concern
levels.
For transactions on a sharded cluster, only the
"snapshot"
read concern provides a consistent snapshot
across multiple shards.
For more information on read concern and transactions, see 트랜잭션 및 읽기 우려.
Write Concerns
writeConcernMajorityJournalDefault
가 false
로 설정된 샤드가 있는 샤딩된 클러스터에서는 트랜잭션을 실행할 수 없습니다. (예: 인메모리 스토리지 엔진을 사용하는 투표 멤버가 있는 샤드)
참고
Regardless of the write concern specified for the
transaction, the commit operation for a
sharded cluster transaction includes some parts that use {w:
"majority", j: true}
write concern.
중재자
복제본 세트 에 중재자 가 있는 경우 트랜잭션 을 사용하여 샤드 키 를 변경할 수 없습니다. 중재자는 멀티 샤드 트랜잭션에 필요한 데이터 작업에 참여할 수 없습니다.
쓰기 작업이 여러 샤드에 걸쳐 있는 트랜잭션은 트랜잭션 작업 중 어떤 것이든 중재자가 포함된 샤드에서 읽거나 쓰는 경우 오류를 발생시키고 중단됩니다.
Backups and Restores
경고
mongodump
및 mongorestore
를 샤딩된 클러스터의 백업 전략으로 사용하려면 데이터베이스 덤프를 사용하여 자체 관리 샤딩된 클러스터 백업을 참조하세요.
또한 샤딩된 클러스터는 샤드 간 트랜잭션의 원자성 보장을 유지하는 다음과 같은 조정된 백업 및 복원 프로세스 중 하나를 사용할 수 있습니다.
Chunk Migrations
청크 마이그레이션은 특정 단계에서 배타 (Exclusive) 컬렉션 락을 획득합니다.
진행 중인 트랜잭션에 컬렉션에 대한 락이 있고 해당 컬렉션을 포함하는 청크 마이그레이션이 시작되면 이러한 마이그레이션 단계는 트랜잭션이 컬렉션에 락을 해제할 때까지 기다려야 하므로 청크 마이그레이션 성능에 영향을 미칩니다.
청크 마이그레이션이 트랜잭션과 중첩되는 경우 (예를 들어 청크 마이그레이션이 이미 진행 중인 동안 트랜잭션이 시작되고, 컬렉션에 대한 락을 트랜잭션이 실행하기 전에 마이그레이션이 완료되는 경우), 트랜잭션은 커밋 시 오류가 발생하고 중단됩니다.
두 작업이 어떻게 교차하는지에 따라 샘플 오류에는 다음과 같습니다. (오류 메시지는 축약됨).
an error from cluster data placement change ... migration commit in progress for <namespace>
Cannot find shardId the chunk belonged to at cluster time ...
다음도 참조하세요.
커밋 중 외부 읽기
트랜잭션을 커밋하는 동안 외부 읽기 작업은 트랜잭션에 의해 수정될 동일한 문서를 읽으려고 할 수 있습니다. 트랜잭션이 여러 샤드에 쓰는 경우 샤드 전체에 걸쳐 커밋을 시도하는 동안 다음이 수행됩니다.
"snapshot"
또는"linearizable"
읽기 우려 (read concern)를 사용하는 외부 읽기는 트랜잭션의 모든 쓰기가 표시될 때까지 기다립니다.인과적으로 일관적인 세션의 일부인 외부 읽기 (AfterClusterTime 포함하는 세션)는 트랜잭션의 모든 쓰기가 표시될 때까지 대기합니다.
다른 읽기 고려 (read concern)를 사용하는 외부 읽기는 트랜잭션의 모든 쓰기가 표시될 때까지 기다리지 않고 대신 문서의 트랜잭션 이전 버전을 읽습니다.
다음도 참조하세요.
추가 정보
See also 프로덕션 고려 사항.