ApsaraDB for MongoDB:トランザクションと読み書きに関する懸念

背景情報

ApsaraDB for MongoDBは、従来のリレーショナルデータベースと同じ方法で使用できます。 ApsaraDB for MongoDBのAPIは、従来のリレーショナルデータベースと同じ方法で使用できます。 学習曲線は含まれない。

トランザクションの例を次に示します。 API (startTransaction、abortTransaction、commitTransaction) および関連するセッション、読み取りの懸念、および書き込みの懸念の設定を表示できます。

// コレクションを作成します。
db.getSiblingDB("mydb1").foo.insertOne ()
    {abc: 0},
    {writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne ()
   {xyz: 0} 、
   {writeConcern: { w: "majority", wtimeout: 2000 } }
)
// セッションを開始します。
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// トランザクションを開始します。
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// トランザクションで操作を実行します。
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (エラー) {
   // エラーが発生したときにトランザクションを中止します。
   session.abortTransaction();
   スローエラー。}
// トランザクションをコミットします。
session.com mitTransaction();
session.endSession(); 

トランザクションを使用する場合は、次の項目に注意してください。

• トランザクションはセッションに関連付けられている必要があります。 セッションは、一度に1つの未処理トランザクションのみを有することができる。 セッションが終了した後、セッションに関連付けられた未処理のトランザクションがロールバックされます。

• 分散トランザクションは、異なるコレクション内の異なるドキュメントに対する操作を同時に含むことができる。

• トランザクションが実行されると、トランザクションは、トランザクションによってコミットされていない書き込み操作を読み取ることができる。 ただし、トランザクションの外部の他の操作は、トランザクションでコミットされていない書き込み操作を読み取ることができません。

• トランザクションに書き込まれたコミットされていないデータは、トランザクションがコミットされるまでセカンダリノードにレプリケートされません。 トランザクションがコミットされると、トランザクションに書き込まれたデータはレプリケートされ、レプリカセットインスタンスのすべてのセカンダリノードに自動的に適用されます。

• ドキュメントを変更すると、トランザクションはドキュメントをロックして、トランザクションが完了するまでドキュメントが他の操作によって変更されないようにします。 トランザクションは、別のトランザクションがすでにロックを保持している可能性があるため、トランザクションが変更する必要があるドキュメントのロックを取得できません。 この場合、トランザクションは中止され、5ミリ秒後に書き込み競合が報告されます。 トランザクションの中止時間は、maxTransactionLockRequestTimeoutMillisカーネルパラメーターによって指定されます。 パラメーターの詳細については、「maxTransactionLockRequestTimeoutMillis」をご参照ください。

• トランザクションは再試行メカニズムの対象となります。 一時的なネットワーク中断などの一時的な再試行エラーが報告された場合、トランザクションは自動的に再試行されます。 クライアントは再試行操作を認識していません。

• トランザクションにはライフサイクルがあります。 60秒を超えて実行されるトランザクションは、バックグラウンドスレッドによって強制的に中止されます。 トランザクションの強制中止時間は、transactionLifetimeLimitSecondsカーネルパラメーターで指定します。 パラメーターの詳細については、「transactionLifetimeLimitSeconds」をご参照ください。

制限

• 分散トランザクションでは、新しいコレクションとインデックスを作成できません。

• トランザクションをキャップ付きコレクションに書き込むことはできません。

• トランザクションでは、スナップショット読み取りコンサートレベルを使用して上限付きコレクションを読み取ることはできません。 これはMongoDB 5.0以降に適用されます。

• トランザクションは、config/admin/localという名前のデータベースのコレクションを読み書きできません。

• トランザクションは、system.* 形式でシステムコレクションにデータを書き込むことはできません。

• トランザクションは説明をサポートしていません。

• トランザクションは、getMoreを使用して、トランザクションの外部で作成されたカーソルを読み取ることはできません。 トランザクションで作成されたカーソルも、トランザクションの外部でgetMoreを使用して読み取ることはできません。

• トランザクションの最初の操作をkillCursors/helloにすることはできません。

• listCollections、listIndexes、createUser、getParameter、countなどのCRUD以外のコマンドは、トランザクションでは実行できません。

• 分散トランザクションのシャードに対して、writeConcernMajorityJournalDefaultパラメーターをfalseに設定することはできません。 パラメーターの詳細については、「writeConcernMajorityJournalDefault」をご参照ください。

• 分散トランザクションは、アービタを含むシャードをサポートしません。 アービタの詳細については、「生産上の考慮事項」をご参照ください。

ベストプラクティス

カーネルリスク

実行時間の長いトランザクションを作成したり、トランザクション内で大量の操作を実行しようとすると、WiredTigerキャッシュの負荷が高くなります。これは、コミットされていないトランザクション内の後続のすべての書き込み操作について、キャッシュがデータを格納し、データステータスを維持する必要があるためです。 進行中のトランザクションは同じスナップショットを使用します。 したがって、トランザクションの実行中に、新しい書き込み操作がWiredTigerキャッシュに蓄積され続けます。 WiredTigerキャッシュの書き込み操作は、古いスナップショットで実行されたトランザクションがコミットまたは中止されるまで削除できます。 ほとんどの場合、長時間のトランザクションによって引き起こされるWiredTigerキャッシュの過負荷により、データベースのストール、応答レイテンシの大幅な増加、CPU使用率の高さ、さらにはビジネスに影響を与えるデッドロックなど、より多くの問題が発生します。 キャッシュの過負荷は、WiredTigerストレージエンジンのキャッシュ使用率とダーティキャッシュ使用率が指定されたしきい値を超えると発生します。 カーネルリスクの詳細については、「SERVER-50365」および「SERVER-51281」をご参照ください。

リスクを防ぐために、長時間実行されるトランザクションを頻繁に処理したり、トランザクションで大量の操作を実行したりするApsaraDB for MongoDBインスタンスをMongoDB 5.0にアップグレードすることを推奨します。

背景情報

Read Concernは、次のデータ一貫性と分離レベルを提供します。 詳細については、「関連情報の読み取り」をご参照ください。

• "local": レプリカセットインスタンスのプライマリノードまたはセカンダリノードに対する読み取りのデフォルト。 データはローカルデータベースから読み取られます。 ロールバックされたデータを読み取ることができる。

• "available": シャードクラスタインスタンスのセカンダリノードに対する読み取りのデフォルト。 ロールバックされたデータを読み取ることができる。 データが読み取られる前に、シャードバージョンはチェックされません。 したがって、孤立した文書を読むことができます。 レベルは、最小のアクセス遅延を提供します。

• 「majority」: 大多数のノードによって肯定応答されたデータが読み取られる。 データはロールバックされません。

• "linearizable": 最高のデータ一貫性を必要とする線形化レベル。 読み出し動作は、全ての書き込み動作が大多数のノードによって確認されるまで待たなければならない。 レベルのパフォーマンスは最も低く、プライマリノードでのみ使用できます。

• 「スナップショット」: 大多数のノードによって肯定応答されるデータは、スナップショットに基づいて読み取られる。 特定の時点におけるスナップショットは、読み出し動作に関連付けることができる。 atClusterTimeパラメーターを設定して、読み取り操作のタイムスタンプを指定できます。 パラメーターの詳細については、「関連の読み取りおよびatClusterTime」をご参照ください。

以下の点にご注意ください。

• mongosノードの最新データは、読み取りの懸念レベルに関係なく、レプリカセットインスタンスの最新バージョンのデータを表すものではありません。

• 操作ごとに異なる読み取り関係レベルを指定できます。 サーバー上でMongoDB 4.4以降を実行するインスタンスの既定の読み取り懸念レベルを指定することもできます。 操作の読み取り関連レベルは、サーバー上のものよりも高い優先度を持っています。

• ローカルデータベースからデータを読み取る場合、指定した読み取り関係レベルは無視されます。 この場合、ローカルデータベースからすべてのローカルデータをいつでも読み取ることができます。

• 分散トランザクションは、"local" 、"majority" 、および "snapshot" 読み取り関連レベルのみをサポートします。

• 因果的に一貫したセッションは、「過半数」の読み取り懸念レベルのみをサポートします。

ベストプラクティス

背景情報

書き込み懸念の詳細については、「書き込み懸念」をご参照ください。

{ w: <value>, j: <boolean>, wtimeout: <number> }

• データ永続性の保証レベルを指定する書き込み懸念は、次のレベルを提供します。

  • {w: 0}: 書き込み操作が完了したことが確認されず、書き込まれたデータが失われる可能性があります。

  • {w: 1}: 書き込み操作の完了が確認されました。 MongoDB 5.0より前のバージョンを実行するインスタンスのデフォルト。 データが永続化されないため、データ損失が発生する可能性があります。

  • {j: true}: 書き込み操作が完了したことが確認され、永続的に格納されたWALログにフラッシュされます。 操作は失われません。

  • { w: "majority" }: 書き込み操作は、操作がレプリカセットインスタンスの大多数のノードにレプリケートされるまで確認できます。 データはロールバックされません。 MongoDB 5.0以降を実行するインスタンスのデフォルト。

  • レプリカ確認: 書き込み操作は、操作がレプリカセットインスタンス内の特定の数のノードにレプリケートされるまで確認できます。

  • カスタム承認: settings.getLastErrorModesパラメーターを設定して、タグを使用して他のカスタム承認方法を指定します。 パラメーターの詳細については、「settings.getLastErrorModes」をご参照ください。

以下の点にご注意ください。

• 書き込み操作またはトランザクションの書き込み関連レベルを指定できます。 レベルを指定しない場合は、デフォルトの書き込み関連レベルが使用されます。

  説明

  MongoDB 5.0以降を実行し、標準の3レプリカトポロジアーキテクチャを使用するインスタンスでは、デフォルトのグローバル書き込み懸念レベルが {w:1} から {w:"majority"} に変更されます。 これにより、インスタンスをMongoDB 5.0にアップグレードした後にパフォーマンスが低下する可能性があります。

• 非表示ノード、レイテンシノード、またはレプリカセットインスタンス内の優先度が0である他のノードは、「多数決」の書き込み懸念レベルで指定されたノードのメンバーと見なすことができます。

• 操作ごとに異なる書き込み懸念レベルを指定できます。 また、サーバー上でMongoDB 4.4以降を実行するインスタンスの既定の書き込み懸念レベルを指定することもできます。 オペレーションの書き込み関連レベルは、サーバ上のものよりも高い優先度を有する。

• データがローカルデータベースに書き込まれると、指定した書き込み関連レベルは無視されます。

• 因果的に一貫したセッションは、「過半数」の書き込み懸念レベルのみをサポートします。

ベストプラクティス