本番環境での考慮事項

可用性

• MongoDB はレプリカセットでのマルチドキュメントトランザクションをサポートします。

• 分散トランザクションは、シャーディングされたクラスターでのマルチドキュメントトランザクションのサポートを追加し、レプリカセットでのマルチドキュメントトランザクションの既存のサポートを組み込んでいます。

機能の互換性

トランザクションを使用するには、配置のすべてのノードの FeatureCompatibilityVersion が次のバージョン以上である必要があります。

ノードの機能の互換性バージョンを確認するには、該当ノードに接続して次のコマンドを実行します。

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

詳細については、setFeatureCompatibilityVersion に関する参考ページを参照してください。

実行時間制限

デフォルトでは、トランザクションの実行時間は 1 分未満である必要があります。この制限は、transactionLifetimeLimitSeconds を使用して mongodインスタンスに対して変更できます。シャーディングされたクラスターの場合、シャーディングされたレプリカセットの全ノードのパラメーターを変更する必要があります。この制限を超えるトランザクションは期限切れと見なされ、定期的なクリーンアップ プロセスによって中止されます。

シャーディングされたクラスターの場合は、commitTransaction に maxTimeMS 制限を指定することもできます。詳細については、「シャーディングされたクラスターのトランザクションの時間制限」を参照してください。

oplog のサイズ制限

MongoDB は、トランザクション内のすべての書込み (write) 操作に対して 1 つのエントリを作成するのではなく、トランザクション内のすべての書込み (write) 操作をカプセル化するために必要な数の oplog エントリを作成します。これにより、すべての書込み (write) 操作に対して、1 つの oplog エントリによって課せられるトランザクションの合計サイズ 16 MB の制限が削除されます。合計サイズの制限はなくなりましたが、各 oplog エントリは BSON ドキュメント サイズ制限の 16MB 以内である必要があります。

WiredTiger キャッシュ

ストレージ キャッシュの負荷がパフォーマンスに悪影響を与えないようにするには、次のようにします。

• トランザクションを放棄する場合は、トランザクションを中止します。

• トランザクションの個々の操作中にエラーが発生した場合は、トランザクションを中止して再試行してください。

transactionLifetimeLimitSecondsは、ストレージ キャッシュの負荷を軽減するために、期限切れのトランザクションが定期的に中止されるようにします。

トランザクションとセキュリティ

• アクセス制御を使用して実行中、トランザクション内の操作に対する権限が必要です。

• 監査付きで実行している場合、中止されたトランザクションの操作は引き続き監査されます。ただし、トランザクションが中止されたことを示す監査イベントはありません。

シャード構成の制限

シャーディングされたクラスターのうち writeConcernMajorityJournalDefault が false に設定されているもの（インメモリ ストレージエンジンを使用する投票ノードのあるシャードなど）ではトランザクションを実行できません。

シャーディングされたクラスターとアービタ

レプリカセットにアービタがある場合、トランザクションを使用してシャードキーを変更することはできません。 アービタは、 マルチシャード トランザクションに必要なデータ操作に参加することはできません。

書込み操作が複数のシャードにまたがるトランザクションで、アービタを含むシャードを対象に読み取りまたは書込み操作が実行される場合、そのトランザクションはエラーとなり中止します。

ロックの取得

デフォルトでは、トランザクションの操作に必要なロックが取得されるまで、トランザクションは最大 5 ミリ秒待機します。トランザクションが 5 ミリ秒以内に必要なロックを取得できない場合、トランザクションは中止されます。

トランザクションによりは、すべてのロックはアボート時やコミット時に解放されます。

保留中の DDL 操作とトランザクション

マルチドキュメントトランザクションが進行中の場合、同じデータベースまたはコレクションに影響する新しい DDL 操作はトランザクションの背後で待機します。これらの保留中の DDL 操作が存在している間、保留中の DDL 操作と同じデータベースまたはコレクションにアクセスする新しいトランザクションは、必要なロックを取得できず、maxTransactionLockRequestTimeoutMillis の時間待機した後に中止されます。さらに、同じデータベースまたはコレクションにアクセスする新しい非トランザクション操作は、maxTimeMS 制限に達するまでブロックされます。

次のシナリオを検討してみましょう。

コレクションのロックが必要な DDL 操作

進行中のトランザクションが hr データベースの employees コレクションに対してさまざまな CRUD 操作を実行している間に、管理者が employees コレクションに対して db.collection.createIndex() DDL 操作を発行します。createIndex()には、コレクションに対して排他コレクション ロックが必要です。

進行中のトランザクションが完了するまで、createIndex() 操作はロックを取得するために待機する必要があります。employeesコレクションに影響し、createIndex() が保留中に開始される新しいトランザクションは、createIndex() が完了するまで待機する必要があります。

保留中の createIndex() DDL 操作は、hr データベース内の他のコレクションのトランザクションには影響しません。たとえば、hr データベースの contractors コレクションに対する新しいトランザクションは、通常どおり開始して完了できます。

データベース ロックが必要な DDL 操作

進行中のトランザクションがhrデータベースのemployeesコレクションに対してさまざまな CRUD 操作を実行している間に、管理者がrenameCollection DDL 操作を発行して、 vendors.contractorsコレクションの名前をhr.contractorsに変更します。 renameCollectionでは、ソース データベース（ vendors ）と異なる場合、ターゲット データベース（ hr ）のデータベース ロックが必要です。

進行中のトランザクションが完了するまで、 renameCollection操作はロックを取得するために待機する必要があります。 hrデータベースまたはそのコレクションのいずれかに影響し、 renameCollectionが保留中に開始される新しいトランザクションは、 renameCollectionが完了するまで待機する必要があります。

どちらのシナリオでも、DDL 操作が maxTransactionLockRequestTimeoutMillis を超えて保留中のままの場合、その操作の背後で待機している保留中のトランザクションは中止されます。つまり、maxTransactionLockRequestTimeoutMillis の値は、少なくとも進行中のトランザクションと保留中の DDL 操作が完了するのに必要な時間をカバーする必要があります。

進行中のトランザクションと書込み競合 (write conflict)

トランザクションが進行中であり、トランザクションの外部への書込み (write) によって変更されたドキュメントに対して、後でトランザクション内の操作によって変更が試みられた場合、書込み競合 (write conflict) によりトランザクションは中止されます。

トランザクションが進行中で、ドキュメントを変更するためにロックがかかっている場合、トランザクション外部の書込み (write) が同じドキュメントを変更しようとすると、その書込み (write) はトランザクションが終了するまで待機します。

進行中のトランザクションと古い読み取り

トランザクション内の読み取り操作によって古いデータが返されることがあります。これをステイル読み取り（古いデータの読み取り）と呼びます。トランザクション内の読み取り操作では、コミットされた他のトランザクションによる書込み (write) やトランザクション以外の書込み (write) が反映されると保証されません。たとえば、次のシーケンスについて考えてみましょう。

1. あるトランザクションが進行中です。

2. トランザクション外の書込み (write) によりドキュメントが削除されます。

3. トランザクション内の読み取り操作では、書込み (write) 操作前のスナップショットが使用されるため、削除されたドキュメントを読み取ることができます。

単一ドキュメントのトランザクション内でのステイル読み取りを回避するには、db.collection.findOneAndUpdate() メソッドを使用できます。次の mongosh の例は、db.collection.findOneAndUpdate() を使用して書込みロック (write lock) を取得し、読み取りが最新になるよう保証する方法を示しています。

db.getSiblingDB("hr").employees.insertOne(
   { _id: 1, status: "Active" }
)

session = db.getMongo().startSession( { readPreference: { mode: "primary" } } )

session.startTransaction( { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } } )
employeesCollection = session.getDatabase("hr").employees

employeeDoc = employeesCollection.findOneAndUpdate(
   { _id: 1, status: "Active" },
   { $set: { lockId: ObjectId() } },
   { returnNewDocument: true }
)

session.commitTransaction()

進行中のトランザクションとチャンクの移行

チャンクの移行では、特定の段階で排他的なコレクション ロックが取得されます。

進行中のトランザクションでコレクションがロックされ、そのコレクションを含むチャンクの移行が開始された場合、これらの移行段階では、トランザクションがコレクションのロックを解放するまで待つ必要があるため、チャンクの移行のパフォーマンスに影響します。

チャンクの移行がトランザクションとインターリーブする場合（たとえば、チャンクの移行がすでに進行中のときにトランザクションが開始され、トランザクションがコレクションをロックする前に移行が完了した場合）、トランザクションはコミット中にエラーになり、中止されます。

2 つの操作がどのようにインターリーブされるかによって、次のようなエラーが出ます（エラーメッセージは省略されています）。

• an error from cluster data placement change ... migration commit in progress for <namespace>

• Cannot find shardId the chunk belonged to at cluster time ...

コミット中の外部読み取り

トランザクションのコミット中に、外部の読み取り操作が、トランザクションによって変更される同じドキュメントを読み込もうとする場合があります。トランザクションが複数のシャードに書き込まれる場合、シャード間でのコミット試行中に次のことが起きます。

• 読み取り保証 (read concern) "snapshot" または "linearizable" を使用する外部読み取りは、トランザクションのすべての書込み (write) が表示可能になるまで待機します。

• 因果的にコンシステントなセッション (afterClusterTime を含むもの）の一部である外部読み取りは、トランザクションのすべての書込みが表示可能になるまで待機します。

• 他の読み取り方法を使用した外部読み取りは、トランザクションのすべての書込みが表示されるまで待たずに、トランザクション前のバージョンのドキュメントを読み取ります。

詳細情報