Aurora マルチマスタークラスターを使用する - Amazon Aurora

Aurora マルチマスタークラスターを使用する

次に、Aurora マルチマスタークラスターについて説明します。マルチマスタークラスターでは、すべての DB インスタンスに読み書き機能がついています。マルチマスタークラスターには、シングルマスタークラスターとは異なる特性の可用性、データベース機能のサポート、およびモニタリングとトラブルシューティングの手順があります。

Aurora マルチマスタークラスターの概要

新しい Aurora クラスターをセットアップするときにマルチマスターまたはシングルマスタークラスターを選択しやすいように、以下の背景情報を使用します。十分な情報に基づいて選択を行うには、スキーマ設計とアプリケーションロジックがマルチマスタークラスターで最適に動作するように計画する方法を最初に理解することをお勧めします。

新しい Amazon Aurora クラスターごとに、シングルマスターとマルチマスターのどちらのクラスターを作成するかを選択できます。

ほとんどの種類の Aurora クラスターは、シングルマスタークラスターです。たとえば、プロビジョニング済み、Aurora Serverless、並列クエリ、およびグローバルデータベースクラスターはすべてシングルマスタークラスターです。シングルマスタークラスターでは、単一の DB インスタンスですべての書き込みオペレーションを実行し、その他の DB インスタンスでは読み取り専用を実行します。書き込み DB インスタンスが使用できなくなると、フェイルオーバーメカニズムにより、読み取り専用インスタンスの 1 つが新しい書き込みになります。

マルチマスタークラスターでは、すべての DB インスタンスで書き込みオペレーションを実行できます。単一の読み書きプライマリインスタンスと、複数の読み取り専用 Aurora レプリカの概念は適用されません。別の書き込み DB インスタンスを使用して、失敗したインスタンスの作業を引き継ぐことができるため、書き込み DB インスタンスが利用できなくなっても、フェイルオーバーが発生することはありません。このような可用性は継続的な可用性と呼ばれ、シングルマスタークラスターによって保証される高可用性 (フェイルオーバー中の短時間のダウンタイムを含む) と区別します。

マルチマスタークラスターは、プロビジョンド、Aurora Serverless、並列クエリクラスターなど、他の種類の Aurora クラスターとは多くの点で動作が異なります。マルチマスタークラスターでは、高可用性、モニタリング、接続管理、データベース機能などの分野でさまざまな要因を考慮してください。たとえば、データベースの書き込みオペレーションで一切のダウンタイムが許容されないアプリケーションでは、マルチマスタークラスターを使用して、書き込みインスタンスが利用できなくなった場合の中断を回避することができます。マルチマスタークラスターでは、別の DB インスタンスに読み書き機能を備えるように昇格する必要がないため、フェイルオーバーメカニズムを使用しません。マルチマスタークラスターでは、単一のプライマリインスタンスではなく、すべての DB インスタンスの DML スループット、レイテンシー、およびデッドロックに関連するメトリクスを検討します。

現在、マルチマスタークラスターには、MySQL 5.6 と互換性のある Aurora MySQL バージョン 1 が必要です。AWS マネジメントコンソール、AWS CLI、または RDS API で DB エンジンのバージョンを指定する場合は、5.6.10a を選択します。

マルチマスタークラスターを作成するには、クラスターの作成時に [データベース機能] で [Multiple writers (複数の書き込み)] を選択します。これにより、DB インスタンス間でのレプリケーション、可用性、およびパフォーマンスについて、他の種類の Aurora クラスターと異なる動作を指定できます。この選択は、クラスターが存続している限り、有効です。マルチマスタークラスターに適した特殊なユースケースについて、必ず理解するようにします。

マルチマスタークラスターの用語

マルチマスタークラスターに関する用語を把握するには、次の定義について理解します。これらの用語は、マルチマスタークラスターのドキュメント全体で使用されます。

書き込み

書き込みオペレーションを実行できる DB インスタンス。Aurora マルチマスタークラスターでは、すべての DB インスタンスが書き込みです。これが、1 つの DB インスタンスのみが書き込みとして動作する Aurora シングルマスタークラスターと大きく異なる点です。書き込みが使用できなくなった場合、シングルマスタークラスターでは、フェイルオーバーメカニズムによって別の DB インスタンスを新しい書き込みに昇格させます。マルチマスタークラスターでは、アプリケーションは、障害が発生した DB インスタンスから、クラスター内の他の DB インスタンスに書き込みオペレーションをリダイレクトすることができます。

マルチマスター

DB インスタンスごとに、読み取りオペレーションと書き込みオペレーションの両方を実行できる Aurora クラスターのアーキテクチャ。これをシングルマスターと比較します。マルチマスタークラスターは、マルチテナントアプリケーションなどのセグメント化されたワークロードに最適です。

シングルマスター

Aurora クラスターのデフォルトアーキテクチャ。単一の DB インスタンス (プライマリインスタンス) で書き込みを実行します。その他のすべての DB インスタンス (Aurora レプリカ) では、読み取り専用のクエリトラフィックを処理します。これをマルチマスターと比較します。このアーキテクチャは、汎用アプリケーションに適しています。そのようなアプリケーションでは、単一の DB インスタンスでデータ操作言語 (DML) およびデータ定義言語 (DDL) ステートメントをすべて処理することができます。スケーラビリティの問題には、主に SELECT クエリが関係します。

書き込みの競合

異なる DB インスタンスが同じデータページを同時に変更しようとしたときに発生する状況。 Aurora は、アプリケーションへの書き込みの競合をデッドロックエラーとしてレポートします。このエラー状態により、トランザクションはロールバックされます。アプリケーションでエラーコードを検出し、トランザクションを再試行する必要があります。

Aurora マルチマスタークラスターの主な設計上の考慮事項とパフォーマンスチューニングの目標は、書き込みの競合を最小限に抑える方法で、DB インスタンス間で書き込みオペレーションを分割することです。そのため、マルチマスタークラスターはシャードアプリケーションに適しています。書き込み競合メカニズムの詳細については、マルチマスタークラスターの競合解決 を参照してください。

シャーディング

セグメント化されたワークロードの特定のクラス。データは、多くのパーティション、テーブル、データベース、または個別のクラスターに物理的に分割されます。データの特定の部分のコンテナは、シャードと呼ばれます。Aurora マルチマスタークラスターでは、各シャードは特定の DB インスタンスによって管理され、DB インスタンスで複数のシャードを管理することができます。シャードされたスキーマの設計は、Aurora マルチマスタークラスターで接続を管理する方法に適切に対応しています。

シャード

シャードされたデプロイ内の詳細度の単位。たとえば、テーブル、関連するテーブルのセット、データベース、パーティション、またはクラスター全体などがあります。Aurora マルチマスタークラスターを使用すると、シャードアプリケーションのデータを単一の Aurora 共有ストレージボリュームに統合して、データベースを継続的に利用できるようにして、容易にデータを管理できます。DB インスタンスごとに管理するシャードを決定します。このマッピングは、データを物理的に再編成せずにいつでも変更することができます。

リシャーディング

シャードされたデータを物理的に再編成して、異なる DB インスタンスで特定のテーブルまたはデータベースを処理できるようにします。ワークロードの変化や DB インスタンスの障害に応じて、Aurora マルチマスタークラスター内のデータを物理的に再編成する必要はありません。クラスター内の DB インスタンスはすべて、共有ストレージボリューム経由でデータベースやテーブルにアクセスできるため、リシャーディングオペレーションを防ぐことができます。

マルチテナント

セグメント化されたワークロードの特定のクラス。各顧客、クライアント、またはユーザーのデータは、個別のテーブルまたはデータベースに保持されます。この設計により、分離が保証され、容量やリソースは個々のユーザーのレベルで管理できます。

Bring-your-own-shard (BYOS)

シャーディングを使用するデータベーススキーマと関連アプリケーションが既にある状況。このようなデプロイは、Aurora マルチマスタークラスターに比較的簡単に転送することができます。この場合、サーバー統合や高可用性などの Aurora の利点の調査に注力することができます。書き込みリクエストの複数の接続を処理するために、新しいアプリケーションロジックを作成する必要はありません。

グローバルな書き込み後読み取り (GRAW)

読み取りオペレーションで常にデータの最新の状態が表示されるように、同期を導入する設定。デフォルトでは、マルチマスタークラスターの読み取りオペレーションで表示されるデータは、レプリケーションラグ (通常は数ミリ秒) の影響を受けます。この短い間隔で、同じデータが別の DB インスタンスによって同時に変更された場合、1 つの DB インスタンスに対するクエリで古いデータが取得される場合があります。この設定を有効にするには、aurora_mm_session_consistency_level をデフォルト設定の INSTANCE_RAW から REGIONAL_RAW に変更します。これにより、読み取りと書き込みを実行する DB インスタンスに関係なく、読み取りオペレーションのクラスター全体の一貫性が保証されます。GRAW モードの詳細については、マルチマスタークラスターの整合性モデル を参照してください。

マルチマスタークラスターアーキテクチャ

マルチマスタークラスターのアーキテクチャは、他の種類の Aurora クラスターとは異なります。マルチマスタークラスターでは、すべての DB インスタンスに読み書き機能が備わっています。他の種類の Aurora クラスターには、すべての書き込みオペレーションを実行する単一の専用 DB インスタンスがありますが、他の DB インスタンスはすべて読み取り専用で、SELECT クエリのみを処理します。マルチマスタークラスターには、プライマリインスタンスまたは読み取り専用の Aurora レプリカはありません。

アプリケーションでは、処理される書き込みリクエストと DB インスタンスが制御されます。したがって、マルチマスタークラスターでは、個々のインスタンスエンドポイントに接続して、DML および DDL ステートメントを発行します。他の種類の Aurora クラスターとは異なります。ここでは通常、書き込みオペレーションはすべて単一のクラスターエンドポイントに、読み取りオペレーションはすべて単一のリーダーエンドポイントに転送されます。

Aurora マルチマスタークラスターの基礎となるストレージは、シングルマスタークラスターのストレージに似ています。データは引き続き、自動的に拡張される信頼性の高い共有ストレージボリュームに保存されます。主な違いは、DB インスタンスの数とタイプです。マルチマスタークラスターには、N 個の読み書きノードがあります。現在、N の最大値は 2 です。

マルチマスタークラスターには、読み取り専用ノードはありません。そのため、Aurora レプリカに関する Aurora の手順とガイドラインは、マルチマスタークラスターには適用されません。一時的に DB インスタンスを読み取り専用にして、さまざまな DB インスタンスに読み取りおよび書き込みのワークロードを配置できます。これを行うには、「インスタンスの読み取り専用モードを使用する」を参照してください。

マルチマスタークラスターノードは、低レイテンシーおよび低遅延の Aurora レプリケーションを使用して接続されます。マルチマスタークラスターでは、all-to-all のピアツーピアレプリケーションを使用します。レプリケーションは書き込み間で直接動作します。書き込みではすべて、その変更は他のすべての書き込みにレプリケートされます。

マルチマスタークラスターの DB インスタンスでは、再起動と復元は別々に処理されます。書き込みを再起動する場合に、他の書き込みも再起動する必要はありません。詳細については、「Aurora マルチマスタークラスターの高可用性に関する考慮事項」を参照してください。

マルチマスタークラスターでは、すべてのデータベースインスタンス内のデータに対する変更をすべて追跡します。測定単位はデータページです。この場合は、固定サイズの 16 KB です。これらの変更には、テーブルデータやセカンダリインデックス、システムテーブルの変更が含まれます。変更は、Aurora の内部ハウスキーピングタスクから生じることもあります。 Aurora では、Aurora が共有ストレージボリュームの各データページと DB インスタンスのメモリに保持する複数の物理コピー間の一貫性を保証します。

2 つの DB インスタンスでほぼ同じ瞬間に同じデータページを変更しようとすると、書き込みの競合が発生します。最も早い変更リクエストは、quorum 投票メカニズムを使用して承認されます。その変更は永続的なストレージに保存されます。変更が承認されていない DB インスタンスでは、試行された変更を含むトランザクション全体がロールバックされます。トランザクションをロールバックすると、データは一貫した状態に保持されるため、アプリケーションでは常にデータの予測可能なビューを表示することができます。アプリケーションでデッドロック状態を検出し、トランザクション全体を再試行できます。

書き込みの競合と関連するパフォーマンスオーバーヘッドを最小限に抑える方法の詳細については、マルチマスタークラスターの競合解決 を参照してください。

マルチマスタークラスターの推奨ワークロード

マルチマスタークラスターは、特定の種類のワークロードで最適に動作します。

アクティブ/パッシブワークロード

アクティブ/パッシブワークロードでは、一度に 1 つの DB インスタンスですべての読み書きオペレーションを実行します。Aurora クラスター内の他の DB インスタンスはすべて予備として保持します。元のアクティブな DB インスタンスが使用できなくなった場合、すべての読み取りおよび書き込みオペレーションをすぐに他の DB インスタンスに切り替えます。この設定により、書き込みオペレーションのダウンタイムを最小限に抑えることができます。他の DB インスタンスは、フェイルオーバーを実行せずにアプリケーションのすべての処理を引き継ぐことができます。

アクティブ/アクティブワークロード

アクティブ/アクティブワークロードでは、すべての DB インスタンスに対して同時に読み取りおよび書き込みオペレーションを実行します。この構成では、通常、異なる DB インスタンスが基になる同一データを同時に変更しないように、ワークロードをセグメント化します。その結果、書き込みの競合の可能性が最小限に抑えられます。

マルチマスタークラスターは、セグメント化されたワークロード用に設計されたアプリケーションロジックで適切に機能します。このタイプのワークロードでは、書き込みオペレーションをデータベースインスタンス、データベース、テーブル、またはテーブルパーティション別に分割します。たとえば、複数のアプリケーションを同じクラスターで実行し、それぞれを特定の DB インスタンスに割り当てることができます。または、複数の小さなテーブル (オンラインサービスのユーザーごとに 1 つのテーブルなど) を使用するアプリケーションを実行できます。理想的には、異なる DB インスタンスの書き込みオペレーションが同じテーブル内の重複する行に対して同時更新を実行しないようにスキーマを設計します。シャードアプリケーションは、この種類のアーキテクチャの一例です。

アクティブ/アクティブのワークロードの設計例については、シャードデータベースでマルチマスタークラスターを使用する を参照してください。

マルチマスタークラスターの利点

Aurora マルチマスタークラスターでは、次の利点を活用できます。

  • マルチマスタークラスターにより、Aurora の高可用性がさらに向上します。クラスター内の他の DB インスタンスを再起動せずに、読み取り/書き込み DB インスタンスを再起動できます。読み取り/書き込み DB インスタンスが使用できなくなった場合でも、フェイルオーバープロセスや、それに伴う遅延はありません。

  • マルチマスタークラスターは、シャードアプリケーションまたはマルチテナントアプリケーションに最適です。データを管理する際、複雑なリシャーディングオペレーションを回避することができます。少数のクラスターまたは DB インスタンスを使用して、シャードアプリケーションを統合できる場合があります。詳細については、「シャードデータベースでマルチマスタークラスターを使用する」を参照してください。

  • Aurora は、書き込みの競合を、トランザクションのコミット時ではなく、即座に検出します。書き込み競合メカニズムの詳細については、マルチマスタークラスターの競合解決 を参照してください。

マルチマスタークラスターの制限

注記

Aurora マルチマスタークラスターは、継続的な可用性のユースケースに非常に特化しています。そのため、このようなクラスターは一般的にすべてのワークロードに適用できるわけではありません。パフォーマンス、スケーラビリティ、および可用性の要件は、Aurora シングルマスタークラスターでより大きな DB インスタンスクラスを使用することで満たすことができます。その場合は、プロビジョニングされたクラスター、または Aurora Serverless クラスターの使用を検討してください。

AWS および Aurora の制限

現在、マルチマスタークラスターで使用できる AWS および Aurora の機能には次の制限が適用されます。

  • 現在、マルチマスタークラスターには最大 2 つの DB インスタンスを使用できます。

  • 現在、マルチマスタークラスター内の DB インスタンスはすべて、同じ AWS リージョンに存在する必要があります。

  • マルチマスタークラスターからクロスリージョンレプリカを有効にすることはできません。

  • マルチマスタークラスターは、次の AWS リージョンで使用できます。

    • 米国東部 (バージニア北部) リージョン

    • 米国東部 (オハイオ) リージョン

    • 米国西部 (オレゴン) リージョン

    • アジアパシフィック (ムンバイ) リージョン

    • アジアパシフィック (ソウル) リージョン

    • アジアパシフィック (東京) リージョン

    • 欧州 (フランクフルト) リージョン

    • 欧州 (アイルランド) リージョン

  • Stop アクションは、マルチマスタークラスターでは使用できません。

  • Aurora の存続可能なページキャッシュ (存続可能なバッファプールとも呼ばれる) は、マルチマスタークラスターではサポートされていません。

  • マルチマスタークラスターでは、接続の負荷分散は行われません。アプリケーションで独自の接続管理ロジックを実装して、複数の DB インスタンスエンドポイント間で読み書きオペレーションを分散する必要があります。通常、bring-your-own-shard (BYOS) アプリケーションには、各シャードを特定の接続にマップするロジックが既にあります。アプリケーションで接続管理ロジックを調整する方法については、「マルチマスタークラスターの接続管理」を参照してください。

  • マルチマスタークラスターには、DB インスタンス間の調整を行う上で、処理とネットワークのオーバーヘッドがあります。このオーバーヘッドは、書き込み重視および読み取り重視のアプリケーションに次の影響を及ぼします。

    • スループットの利点は、複数の同時書き込みオペレーションを行うビジー状態のクラスターに最も顕著に表れます。通常、単一のプライマリインスタンスを持つ従来の Aurora クラスターでは、クラスターの書き込みトラフィックを処理できます。このような場合、マルチマスタークラスターの利点は、パフォーマンスではなく高可用性にあります。

    • 通常、単一クエリのパフォーマンスは、同等のシングルマスタークラスタのパフォーマンスよりも低くなります。

  • シングルマスタークラスターで作成されたスナップショットを取得して、マルチマスタークラスターで復元することはできません。代わりに、1 種類のクラスターから他のクラスターにすべてのデータを転送するには、AWS Database Migration Service (AWS DMS) や mysqldump コマンドなどのツールによって作成された論理ダンプを使用します。

  • マルチマスタークラスターでは、並列クエリ、Aurora Serverless、またはグローバルデータベース機能を使用できません。

    マルチマスターは、クラスターの永続的な選択肢です。既存の Aurora クラスターをマルチマスタークラスターや別の種類 (Aurora Serverless クエリや並列クエリなど) との間で切り替えることはできません。

  • ゼロダウンタイムパッチ (ZDP) およびゼロダウンタイムリスタート (ZDR) 機能は、マルチマスタークラスターでは使用できません。

  • マルチマスタークラスターでは、他の AWS のサービス (AWS Lambda、Amazon S3、AWS Identity and Access Management など) との統合を行うことはできません。

  • Performance Insights 機能は、マルチマスタークラスターでは使用できません。

  • マルチマスタークラスターのクローンを作成することはできません。

  • マルチマスタークラスターのバックトラック機能を有効にすることはできません。

データベースエンジンの制限

マルチマスタークラスターで使用できるデータベースエンジン機能には、次の制限が適用されます。

  • マルチマスタークラスターとの間でバイナリログ (binlog) レプリケーションを実行することはできません。この制限は、マルチマスタークラスターでグローバルトランザクション ID(GTID) レプリケーションも使用できないことを意味します。

  • イベントスケジューラーは、マルチマスタークラスターでは使用できません。

  • ハッシュ結合の最適化は、マルチマスタークラスターでは有効になっていません。

  • クエリキャッシュは、マルチマスタークラスターでは使用できません。

  • マルチマスタークラスターでは特定の SQL 言語機能を使用できません。SQL の相違点を示す詳細なリスト、およびこれらの制限に対処するための SQL コードの適合に関する指示については、マルチマスタークラスターの SQL に関する考慮事項 を参照してください。

Aurora マルチマスタークラスターの作成

Aurora クラスターの作成時に、マルチマスターまたはシングルマスターのアーキテクチャを選択します。次の手順は、マルチマスターを選択する場所を示しています。Aurora クラスターを以前に作成したことがない場合は、Amazon Aurora DB クラスターの作成 で一般的な手順を確認できます。

AWS マネジメントコンソール から Aurora マルチマスタークラスターを作成するには、次のように選択します。最初の画面で、Aurora クラスターを選択します。


            Aurora マルチマスタークラスターの作成: Aurora データベースエンジンの選択

また、MySQL 5.6 の互換性と場所 [Regional] を選択します。


            Aurora マルチマスタークラスターの作成: MySQL 5.6 と互換性のある Aurora MySQL データベースエンジンの選択

2 番目の画面で、[Multiple writers (複数の書き込み)] の [Database features (データベース機能)] を選択します。


            Aurora マルチマスタークラスターの作成: 複数の書き込みの選択

クラスターの他の設定を入力します。手順のこの部分は、DB クラスターの作成 で Aurora クラスターを作成する一般的な手順と同じです。

マルチマスタークラスターを作成したら、「DB クラスターに Aurora レプリカを追加する」の手順に従って、2 つの DB インスタンスを追加します。マルチマスタークラスター内のすべての DB インスタンスに同じ AWS インスタンスクラスを使用します。

マルチマスタークラスターと関連する DB インスタンスを作成すると、次のように AWS マネジメントコンソール の [Databases] ページにクラスターが表示されます。すべての DB インスタンスのロールに [Writer] が表示されます。


            マルチマスタークラスターを示す RDS コンソールの データベースページ

AWS CLI を使用してマルチマスタークラスターを作成するには、 create-db-cluster AWS CLI コマンドを実行し、オプション --engine_mode=multimaster を含めます。

次のコマンドは、マルチマスターレプリケーションで Aurora クラスターを作成するための構文を示します。Aurora クラスターを作成する一般的な手順については、DB クラスターの作成 を参照してください。

Linux、macOS、Unix の場合:

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora \ --engine-version 5.6.10a --master-username user-name --master-user-password password \ --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id \ --engine-mode multimaster

Windows の場合:

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora ^ --engine-version 5.6.10a --master-username user-name --master-user-password password ^ --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id ^ --engine-mode multimaster

マルチマスタークラスターを作成したら、「DB クラスターに Aurora レプリカを追加する」の手順に従って、2 つの DB インスタンスを追加します。マルチマスタークラスター内のすべての DB インスタンスに同じ AWS インスタンスクラスを使用します。

RDS API を使用してマルチマスタークラスターを作成するには、CreateDBCluster オペレーションを実行します。EngineMode パラメータに multimaster 値を指定します。Aurora クラスターを作成する一般的な手順については、DB クラスターの作成 を参照してください。

マルチマスタークラスターを作成したら、「DB クラスターに Aurora レプリカを追加する」の手順に従って、2 つの DB インスタンスを追加します。マルチマスタークラスター内のすべての DB インスタンスに同じ AWS インスタンスクラスを使用します。

DBインスタンスをマルチマスタークラスターに追加する

マルチマスタークラスターの利点を確認するには、複数の DB インスタンスが必要です。 「DB クラスターに Aurora レプリカを追加する」の手順を使用して、後で別の DB インスタンスを作成できます。マルチマスタークラスターの違いは、新しい DB インスタンスには読み取り専用の Aurora レプリカではなく読み書き機能がある点です。マルチマスタークラスター内のすべての DB インスタンスに同じ AWS インスタンスクラスを使用します。

Aurora マルチマスタークラスターを管理する

Aurora マルチマスタークラスターのほとんどの管理を、他の種類の Aurora クラスターと同じ方法で行います。次のセクションでは、管理用のマルチマスタークラスターの違いと独自の機能について説明します。

Aurora マルチマスタークラスターのモニタリング

MySQL および Aurora シングルマスタークラスターでサポートされているモニタリングや診断機能は通常、マルチマスタークラスターでもサポートされています。

  • MySQL エラーログ、一般ログ、スロークエリログ。

  • SHOW コマンド、ステータス変数、InnoDB ランタイムステータステーブルなどの MySQL 組み込み診断機能。

  • MySQL パフォーマンススキーマ。

  • 高度な監査。

  • CloudWatch メトリクス。

  • 拡張モニタリング。

Aurora マルチマスタークラスターは現在、次のモニタリング機能をサポートしていません。

  • パフォーマンスインサイト。

マルチマスタークラスターのデータ取り込みパフォーマンス

マルチマスタークラスタでの DML オペレーションのベストプラクティスのひとつに、トランザクションを小さく簡潔に保つことがあります。また、特定のテーブルまたはデータベースの書き込みオペレーションを特定の DB インスタンスにルーティングします。一括インポートを行うには、トランザクションサイズのガイダンスを緩和する必要がある場合があります。ただし、書き込みオペレーションを分散して、書き込みの競合の可能性を最小限に抑えることができます。

一括インポートから書き込みワークロードを分散するには

  1. スキーマ内のデータベース、テーブル、またはその他のオブジェクトごとに個別の mysqldump コマンドを発行します。mysqldump ごとの結果を、ダンプされるオブジェクトを反映した名前のファイルに保存します。別の方法として、mydumper などの複数のテーブルを自動的に並行してダンプできる専用のダンプおよびインポートツールを使用できます。

  2. データファイルごとに個々に mysql セッションを実行し、対応するスキーマオブジェクトを処理する適切なインスタンスエンドポイントに接続します。繰り返しますが、代替として、myloader などの特殊な並列インポートコマンドを使用できます。

  3. インポートセッションで次のセッションを開始する前に各セッションを完了するのを待つのではなく、マルチマスタークラスターの DB インスタンス全体で並行してインポートセッションを実行します。

以下の方法を使用して、データを Aurora マルチマスタークラスターにインポートできます。

  • ステートメントが Aurora でサポートされていない機能を使用しない場合、他の MySQL 互換サーバーから Aurora マルチマスタークラスターに論理 (SQL 形式) ダンプをインポートできます。たとえば、マルチマスタークラスターでは FTS 機能がサポートされていないため、MySQL 全文検索 (FTS) インデックスを含むテーブルからの論理ダンプは機能しません。

  • DMS などのマネージドサービスを使用して、データを Aurora マルチマスタークラスターに移行できます。

  • MySQL と互換性のないサーバーから Aurora マルチマスタークラスターへの移行については、異種間の Aurora の移行の既存の指示に従ってください。

  • Aurora マルチマスタークラスターでは、SQL 形式で MySQL 互換の論理ダンプを生成できます。このような形式を理解できる移行ツール (例: AWS DMS) では、Aurora マルチマスタークラスターからのデータダンプを消費できます。

  • Aurora では、マルチマスタークラスターを binlog マスターまたはワーカーとして使用するバイナリログをサポートしていません。マルチマスタークラスターでは、binlog ベースの CDC ツールを使用できません。

  • MySQL 互換でないサーバーから移行する場合、AWS DMS の継続変更データキャプチャ (CDC) 機能を使用してマルチマスタークラスターにレプリケートできます。このタイプのレプリケーションは、SQL ステートメントを宛先クラスターに送信するため、binlog レプリケーションの制限は適用されません。

移行方法と推奨事項の詳細については、AWS ホワイトペーパー「Amazon Aurora 移行ハンドブック」を参照してください。このハンドブックに記載されている移行方法の一部は、Aurora マルチマスタークラスターには適用されない場合がありますが、このドキュメントは、Aurora 移行トピックに関する総合的な知識を提供します。

マルチマスタークラスターからデータをエクスポートする

マルチマスタークラスターのスナップショットを保存し、別のマルチマスタークラスターに復元することができます。現在、マルチマスタークラスタースナップショットをシングルマスタークラスターに復元することはできません。

マルチマスタークラスターからシングルマスタークラスターにデータを移行するには、論理ダンプを使用し、mysqldump などのツールで復元します。

バイナリログレプリケーションのソースまたは宛先としてマルチマスタークラスターを使用することはできません。

Aurora マルチマスタークラスターの高可用性に関する考慮事項

Aurora マルチマスタークラスターでは、他のインスタンスを再起動することなく、DB インスタンスを再起動できます。この動作により、Aurora シングルマスタークラスターよりも、優れた読み書き接続と読み取り専用接続の可用性を実現できます。この可用性レベルは、継続的な可用性とも呼ばれます。マルチマスタークラスターでは、書き込み DB インスタンスに障害が発生しても、書き込みの可用性に対するダウンタイムはありません。クラスターインスタンスはすべて書き込み可能であるため、マルチマスタークラスターではフェイルオーバーメカニズムは使用されません。マルチマスタークラスターで DB インスタンスに障害が発生した場合、アプリケーションはワークロードを残りの正常なインスタンスにリダイレクトできます。

シングルマスタークラスターでは、プライマリインスタンスを再起動すると、フェイルオーバーメカニズムが新しいプライマリインスタンスを昇格するまで書き込みオペレーションが使用できなくなります。読み取り専用オペレーションでは、クラスター内のすべての Aurora レプリカが再起動するため、短時間のダウンタイムも発生します。

マルチマスタークラスター内のアプリケーションのダウンタイムを最小限に抑えるには、SQL レベルの高頻度のヘルスチェックを実装します。マルチマスタークラスターの DB インスタンスが使用できなくなった場合、予想される停止時間の長さとワークロードでの書き込みオペレーションの緊急度に基づき、実行する内容を判別できます。停止が短時間で、書き込みオペレーションが緊急でないと予想される場合は、DB インスタンスが回復するのを待ってから、その DB インスタンスが通常処理するワークロードを再開できます。または、そのワークロードを別の DB インスタンスにリダイレクトできます。基になるデータは、クラスター内のすべての DB インスタンスで常に利用可能です。高度に分散された Aurora ストレージボリュームでは、AZ 全体に障害が発生する可能性が低い場合でも、データを継続的に使用することができます。利用できない DB インスタンスから書き込みオペレーションを切り替えるためのタイミングの考慮事項については、「マルチマスタークラスターをアクティブスタンバイとして使用する」を参照してください。

マルチマスタークラスターと他のクラスター間のレプリケーション

マルチマスタークラスターは、着信または発信のバイナリログレプリケーションをサポートしていません。

マルチマスタークラスターのアップグレード

Aurora マルチマスタークラスターは、他の種類の Aurora クラスターと同じバージョン番号付けスキームを使用し、メジャーバージョン番号とマイナーバージョン番号を使用します。ただし、[マイナーバージョン自動アップグレードの有効化] 設定は、マルチマスタークラスターには適用されません。

Aurora マルチマスタークラスターをアップグレードすると、通常、アップグレード手順により、データベースエンジンが現在のバージョンから次の上位バージョンに移行されます。バージョン番号が 2 以上高くなる Aurora バージョンにアップグレードする場合は、マルチステップのアプローチを使用します。各 DB インスタンスは、現在の 1 つ上のバージョンにアップグレードされてから、その次のバージョンにアップグレードされます。同様に、指定されたアップグレードバージョンに達するまで続きます。

このアプローチは、古いバージョンと新しいバージョンの間に後方互換性のない変更があるかどうかによって異なります。たとえば、システムスキーマの更新は、後方互換性のない変更と見なされます。特定のバージョンに後方互換性のない変更が含まれているかどうかは、リリースノートを参照して確認できます。

古いバージョンと新しいバージョンの間に互換性のない変更がない場合、各 DB インスタンスは個別にアップグレードおよび再起動されます。クラスター全体でダウンタイムが発生しないように、アップグレードは時間をずらして行われます。アップグレードプロセス中、少なくとも 1 つの DB インスタンスをいつでも使用できます。

古いバージョンと新しいバージョンの間に互換性のない変更がある場合、Aurora はオフラインモードでアップグレードを実行します。すべてのクラスターノードが同時にアップグレードされ、再起動されます。古いエンジンによって、新しいシステムテーブルに書き込まれるのを防ぐために、クラスターで短時間のダウンタイムが発生します。

ゼロダウンタイムパッチ (ZDP) は現在、Aurora マルチマスタークラスターではサポートされていません。

Aurora マルチマスタークラスターのアプリケーションに関する考慮事項

次に、マルチマスタークラスターとシングルマスタークラスターの機能サポートまたは動作の相違により、アプリケーションで必要になる変更について説明します。

マルチマスタークラスターの SQL に関する考慮事項

マルチマスタークラスターで使用できる SQL 言語機能に適用される主な制限を以下に示します。

  • マルチマスタークラスターでは、行レイアウトを変更する特定の設定または列タイプを使用できません。innodb_large_prefix 設定オプションを有効にすることはできません。列タイプ MEDIUMTEXTMEDIUMBLOBLONGTEXT、または LONGBLOB は使用できません。

  • マルチマスタークラスター内の外部キー列で CASCADE 句を使用することはできません。

  • マルチマスタークラスターには、フルテキスト検索 (FTS) インデックスを持つテーブルを含めることはできません。このようなテーブルをマルチマスタークラスター上に作成したり、インポートしたりすることはできません。

  • DDL は、マルチマスタークラスターとシングルマスタークラスターで動作が異なります。たとえば、高速 DDL メカニズムはマルチマスタークラスターでは使用できません。テーブルで DDL を実行している間は、マルチマスタークラスター内のテーブルに書き込むことはできません。DDL の違いの詳細については、マルチマスタークラスターで DDL オペレーションを実行する を参照してください。

  • マルチマスタークラスターで SERIALIZABLE トランザクション分離レベルを使用することはできません。Aurora シングルマスタークラスターでは、プライマリインスタンスでこの分離レベルを使用できます。

  • 自動インクリメント列は、auto_increment_increment および auto_increment_offset パラメータを使用して処理されます。パラメータ値は事前に決められているため、設定できません。パラメータ auto_increment_increment は 16 に設定されます。これは、Aurora クラスター内のインスタンスの最大数です。ただし、マルチマスタークラスターには現在、DB インスタンスの数の下限があります。詳細については、「自動インクリメント列の使用」を参照してください。

アプリケーションを Aurora マルチマスタークラスターに適応させる場合は、移行と同じようにそのアクティビティにアプローチします。特定の SQL 機能の使用を停止し、他の SQL 機能のアプリケーションロジックを変更する必要がある場合があります。

  • CREATE TABLE ステートメントで、MEDIUMTEXTMEDIUMBLOBLONGTEXT、または LONGBLOB として定義されている列を、オフページストレージが不要な短い型に変更します。

  • CREATE TABLE ステートメントで、外部キー宣言から CASCADE 句を削除します。必要に応じてアプリケーションロジックを追加し、INSERT または DELETE を使用して CASCADE 効果をエミュレートします。

  • InnoDB 全文検索 (FTS) インデックスの使用を削除します。SELECT ステートメントで MATCH() 演算子、DDL ステートメントで FULLTEXT キーワードのソースコードを確認します。INFORMATION_SCHEMA.INNODB_SYS_TABLES システムテーブルのテーブル名に文字列 FTS_ が含まれているかどうかを確認します。

  • アプリケーションで CREATE TABLEDROP TABLE などの DDL オペレーションの頻度を確認します。マルチマスタークラスターでは DDL オペレーションのオーバーヘッドが大きくなるため、小さな DDL ステートメントを多数実行しないでください。たとえば、必要なテーブルを事前に作成するタイミングを探します。マルチマスタークラスターとの DDL の違いについては、マルチマスタークラスターで DDL オペレーションを実行する を参照してください。

  • 自動インクリメント列の使用状況を検討します。マルチマスタークラスターでは、自動インクリメント列の値のシーケンスは、他の種類の Aurora クラスターとは異なります。DDL ステートメントの AUTO_INCREMENT キーワード、SELECT ステートメントの関数名 last_insert_id()、およびカスタム構成設定の名前 innodb_autoinc_lock_mode を確認します。相違点とその処理方法の詳細については、「自動インクリメント列の使用」を参照してください。

  • SERIALIZABLE キーワードのコードを確認してください。このトランザクション分離レベルをマルチマスタークラスターで使用することはできません。

マルチマスタークラスターの接続管理

マルチマスタークラスターの接続に関する主な考慮事項は、使用可能な DNS エンドポイントの数と種類です。マルチマスタークラスターでは、他の種類の Aurora クラスターではほとんど使用しないインスタンスエンドポイントを使用することがよくあります。

Aurora マルチマスタークラスターには、次の種類のエンドポイントがあります。

クラスターエンドポイント

このタイプのエンドポイントは、常に読み書き機能を持つ DB インスタンスを指します。マルチマスタークラスターごとに 1 つのクラスターエンドポイントがあります。

マルチマスタークラスターのアプリケーションには通常、特定の DB インスタンスへの接続を管理するロジックが含まれているため、このエンドポイントを使用する必要はほとんどありません。これは、管理を実行するためにマルチマスタークラスターに接続する場合に最も役立ちます。

クラスター内の DB インスタンスのステータスがわからない場合は、このエンドポイントに接続してクラスタートポロジを調べることもできます。その手順については、クラスタートポロジを指定する を参照してください。

DB インスタンスのエンドポイント

このタイプのエンドポイントは、特定の名前付き DB インスタンスに接続されます。Aurora マルチマスタークラスターの場合、アプリケーションは通常、すべてまたはほぼすべての接続に DB インスタンスエンドポイントを使用します。シャードとクラスター内の DB インスタンス間のマッピングに基づき、各 SQL ステートメントに使用する DB インスタンスを決定します。各 DB インスタンスには、そのようなエンドポイントが 1 つあります。そのため、マルチマスタークラスターにはこれらのエンドポイントが 1 つ以上あり、DB インスタンスがマルチマスタークラスターに追加または削除されると、その数は変化します。

DB インスタンスエンドポイントの使用方法は、シングルマスタークラスターとマルチマスタークラスターとで異なります。シングルマスタークラスターの場合、通常、このエンドポイントを頻繁に使用することはありません。

カスタムエンドポイント

このタイプのエンドポイントはオプションです。1 つ以上のカスタムエンドポイントを作成して、特定の目的のために DB インスタンスをグループ化できます。エンドポイントに接続すると、Aurora は毎回異なる DB インスタンスの IP アドレスを返します。マルチマスタークラスターでは、通常、カスタムエンドポイントを使用して、主に読み取りオペレーションに使用する DB インスタンスのセットを指定します。書き込みオペレーションの負荷を分散するために、マルチマスタークラスターでカスタムエンドポイントを使用しないことをお勧めします。使用すると、書き込みの競合が発生する可能性が高くなります。

マルチマスタークラスターにはリーダーエンドポイントがありません。実際には、通常は同じテーブルに書き込む同じ DB インスタンスエンドポイントを使用して SELECT クエリを発行します。そうすることで、バッファプールのキャッシュデータをより効果的に使用でき、クラスター内のレプリケーションラグによる古いデータの潜在的な問題を回避できます。同じテーブルに書き込む同じ DB インスタンスに SELECT ステートメントを配置せず、特定のクエリの書き込み後の読み取りを厳密に保証する必要がある場合は、マルチマスタークラスターの整合性モデル に記載されているグローバルな書き込み後読み取り (GRAW) メカニズムを使用して、このようなクエリを実行することを検討してください。

Aurora および MySQL 接続管理の一般的なベストプラクティスについては、 AWS ホワイトペーパー「Amazon Aurora 移行ハンドブック」を参照してください。

マルチマスター DB クラスターで読み取り専用 DB インスタンスをエミュレートする方法については、「インスタンスの読み取り専用モードを使用する」を参照してください。

カスタム DNS エンドポイントを作成し、Aurora マルチマスタークラスターのドライバーとコネクターを設計するときは、以下のガイドラインに従ってください。

  • DDL、DML、および DCL ステートメントの場合、ラウンドロビン方式またはランダム方式で動作するエンドポイントまたは接続ルーティング技術を使用しないでください。

  • これらのトランザクションがクラスター内の他の書き込みトラフィックと競合しないことが保証されていない限り、長時間実行される書き込みクエリと長時間の書き込みトランザクションは避けてください。

  • 自動コミットされたトランザクションを使用することをお勧めします。実用的な場合は、グローバルレベルまたはセッションレベルでの autocommit=0 の設定を避けてください。プログラミング言語にデータベースコネクタまたはデータベースフレームワークを使用する場合、コネクタまたはフレームワークを使用するアプリケーションで autocommit がオンになっていることを確認してください。必要に応じて、コード全体の論理ポイントに COMMIT ステートメントを追加して、トランザクションが簡潔になるようにします。

  • グローバルな読み取りの一貫性、または書き込み後読み取り (GRAW) の保証が必要な場合は、マルチマスタークラスターの整合性モデル に記載されているグローバルな書き込み後読み取り (GRAW) の推奨事項に従ってください。

  • 実用的な場合は、DDL および DCL ステートメントにクラスターエンドポイントを使用します。クラスターエンドポイントは、個々の DB インスタンスのホスト名への依存を最小限に抑えるのに役立ちます。DML ステートメントの場合のように、テーブルまたはデータベースごとに DDL ステートメントと DCL ステートメントを分ける必要はありません。

マルチマスタークラスターの整合性モデル

Aurora マルチマスタークラスターは、セッションレベルで構成可能なグローバルな書き込み後読み取り (GRAW) モードをサポートします。この設定により、追加の同期が導入され、各クエリの一貫した読み取りビューが作成されます。このように、クエリで常に最新のデータを参照することができます。デフォルトでは、マルチマスタークラスターのレプリケーションラグによって、データが更新されてから数ミリ秒間、DB インスタンスで古いデータが参照される可能性があることを意味します。クエリが結果として待機する必要がある場合でも、アプリケーションが他の DB インスタンスによって行われた最新のデータ変更を参照するクエリに依存している場合は、この機能を有効にします。

注記

同じ DB インスタンスを使用してデータを書き込んでから読み取る場合、レプリケーションラグはクエリ結果に影響しません。したがって、GRAW 機能は主に、異なる DB インスタンスを介して複数の同時書き込みオペレーションを発行するアプリケーションに適用されます。

GRAW モードを使用する場合、すべてのクエリに対してデフォルトで有効にしないでください。グローバルに一貫した読み取りは、ローカルな読み取りよりも大幅に遅くなります。そのため、必要なクエリには GRAW を選択的に使用します。

GRAW を使用する際の次の考慮事項に注意してください。

  • GRAW では、クラスター全体で一貫した読み取りビューを確立するためのコストが原因でパフォーマンスのオーバーヘッドが発生します。トランザクションでは最初にクラスター全体の一貫した時点を決定し、その後レプリケーションでその時点に追いつく必要があります。合計遅延時間はワークロードによって異なりますが、通常は数十ミリ秒の範囲です。

  • トランザクション内で GRAW モードを変更することはできません。

  • 明示的なトランザクションなしで GRAW を使用すると、個々のクエリごとに、グローバルに一貫した読み取りビューを確立するパフォーマンスオーバーヘッドが発生します。

  • GRAW を有効にすると、読み取りと書き込みの両方にパフォーマンスのペナルティが適用されます。

  • 明示的なトランザクションで GRAW を使用する場合、グローバルに一貫性のあるビューを確立するオーバーヘッドは、トランザクションの開始時に各トランザクションに 1 回適用されます。トランザクションの後半で実行されるクエリは、GRAW なしで実行した場合と同じくらい高速です。連続する複数のステートメントがすべて同じ読み取りビューを使用できる場合、全体的なパフォーマンスを向上させるために、それらを単一のトランザクションにラップできます。これにより、ペナルティはクエリごとではなくトランザクションごとに 1 回のみ適用されます。

マルチマスタークラスターとトランザクション

標準の Aurora MySQL ガイダンスは、Aurora マルチマスタークラスターに適用されます。Aurora MySQL データベースエンジンは、使用期間が短い SQL ステートメント用に最適化されています。これらは、通常、オンライントランザクション処理 (OLTP) アプリケーションに関連付けられているステートメントのタイプです。

特に、書き込みトランザクションをできるだけ短くすることができます。その結果、書き込みの競合を抑えることができます。競合解決メカニズムはオプティミスティックで、書き込みの競合が少ない場合に最高のパフォーマンスを発揮します。トレードオフは、競合が発生すると、大幅なオーバーヘッドが発生することを意味します。

大規模なトランザクションによるメリットがある特定のワークロードがあります。たとえば、単一ステートメントトランザクションではなく、マルチメガバイトのトランザクションを使用して実行する場合は、一括データインポートの方が非常に高速に処理することができます。このようなワークロードの実行中に許容できない数の競合が発生する場合は、次のオプションを検討してください。

  • トランザクションサイズを小さくします。

  • バッチジョブがオーバーラップせず、他のワークロードとの競合を引き起こさないように、バッチジョブを再スケジュールまたは再配置します。可能であれば、オフピーク時に実行されるようにバッチジョブを再スケジュールします。

  • 競合を引き起こす他のトランザクションと同じ書き込みインスタンスで実行されるように、バッチジョブをリファクタリングします。競合するトランザクションが同じインスタンスで実行されると、トランザクションエンジンによって、行へのアクセスが管理されます。その場合、ストレージレベルの書き込みの競合は発生しません。

マルチマスタークラスターでの書き込みの競合とデッドロック

マルチマスタークラスターの重要なパフォーマンスの側面に、書き込みの競合の頻度があります。Aurora ストレージサブシステムでこのような問題状態が発生すると、アプリケーションにデッドロックエラーが送信され、アプリケーションは、デッドロック状態に対して通常のエラー処理を実行します。Aurora は、このような競合がまれな場合に最高のパフォーマンスを発揮するロックフリーのオプティミスティックアルゴリズムを使用します。

マルチマスタークラスターでは、すべての DB インスタンスから共有ストレージボリュームに書き込むことができます。変更するデータページごとに、Aurora は複数のアベイラビリティーゾーン (AZ) に複数のコピーを自動的に配布します。複数の DB インスタンスが非常に短い時間内に同じデータページを変更しようとすると、書き込みの競合が発生する可能性があります。Aurora ストレージサブシステムは、変更がオーバーラップしていることを検出し、書き込みオペレーションを完了する前に競合を解決します。

Aurora は、固定サイズが 16 KiB の物理データページのレベルで書き込みの競合を検出します。したがって、行が両方とも同じデータページ内にある場合は、異なる行に影響する変更に対しても競合が発生する可能性があります。

競合が発生した場合、クリーンアップ操作には、DB インスタンスの 1 つからの変更を取り消すための追加作業が必要です。アプリケーションの観点から、競合の原因となったトランザクションはデッドロックし、Aurora はそのトランザクション全体をロールバックします。アプリケーションにはエラーコード 1213 が送信されます。

トランザクションを元に戻すには、変更がすでに Aurora ストレージサブシステムに適用されている他の多くのデータページを変更する必要がある場合があります。トランザクションによって変更されたデータの量によっては、元に戻すために大幅なオーバーヘッドが伴う場合があります。したがって、書き込みの競合の可能性を最小限に抑えることは、Aurora マルチマスタークラスターの設計上の重要な考慮事項です。

一部の競合は、ユーザーが行った変更に起因します。これらの変更には、SQL ステートメント、トランザクション、およびトランザクションのロールバックなどがあります。これらの種類の競合は、スキーマ設計とアプリケーションの接続管理ロジックにより最小限に抑えることができます。

他の競合は、SQL ステートメントと内部サーバースレッドの両方からの同時変更が原因で発生します。これらの競合は、不明な内部サーバーのアクティビティに依存するため、予測が困難です。これらの競合を引き起こす主な内部アクティビティは、ガベージコレクション (purge として知られる) と Aurora によって自動的に実行されるトランザクションロールバックの 2 つです。たとえば、Aurora はクラッシュリカバリ中またはクライアント接続が失われた場合に自動的にロールバックを実行します。

トランザクションのロールバックは、すでに行われたページの変更を物理的に元に戻します。ロールバックでは、元のトランザクションと同様にページの変更を生成します。ロールバックには時間がかかり、元のトランザクションの数倍になる可能性があります。ロールバックの進行中に、ロールバックが生成する変更がトランザクションと競合する可能性があります。

ガベージコレクションは、マルチバージョンコンカレンシーコントロール (MVCC) に関係しています。これは、Aurora MySQL トランザクションエンジンで使用される同時実行制御方法です。MVCC では、データ変更により新しい行バージョンが作成され、データベースは行の複数のバージョンを保持して、データへの同時アクセスを許可しながらトランザクションの分離を実現します。行バージョンは、不要になると削除 (パージ) されます。ここでも、パージのプロセスによってページが変更され、トランザクションと競合する可能性があります。ワークロードに応じて、データベースはパージラグ (ガベージコレクションを待機している変更のキュー) を発生させる可能性があります。遅延が大幅に増加すると、SQL ステートメントの送信を停止した場合でも、データベースがパージを完了するのにかなりの時間が必要になる場合があります。

内部サーバースレッドで書き込みの競合が発生した場合、Aurora は自動的に再試行します。対照的に、アプリケーションは、競合が発生したトランザクションの再試行ロジックを処理する必要があります。

同じ DB インスタンスからの複数のトランザクションがこれらの種類の重複する変更を引き起こす場合、Aurora は標準のトランザクション同時実行性ルールを使用します。たとえば、同じDBインスタンス上の 2 つのトランザクションが同じ行を変更すると、そのいずれかは待機します。待機が設定されたタイムアウト (innodb_lock_wait_timeout、デフォルトでは 50 秒) よりも長い場合、待機中のトランザクションは「Lock wait timeout exceeded」というメッセージで中止されます。

マルチマスタークラスターと読み取りのロック

Aurora マルチマスタークラスターは、次の形式で読み取りのロックをサポートします。

SELECT ... FOR UPDATE SELECT ... LOCK IN SHARE MODE

読み取りのロックの詳細については、「MySQL リファレンスマニュアル」を参照してください。

読み取りオペレーションのロックはすべてのノードでサポートされていますが、ロック範囲はコマンドが実行されたノードに対してローカルです。ある書き込みで実行される読み取りロックによって、他の書き込みによる、ロックされた行へのアクセスや変更に影響することはありません。この制限にもかかわらず、シャードまたはマルチテナントデータベースなど、書き込み間のワークロードスコープの厳密な分離を保証するユースケースで、読み取りロックを使用できます。

以下のガイドラインを検討します。

  • ノードは、それ自体の変更を即座にかつ遅延なく、常に確認できる点に注意してください。必要に応じて、GRAW 要件を排除できるように、読み取りと書き込みを同じノードに配置することができます。

  • 読み取り専用クエリをグローバルに一貫した結果で実行する必要がある場合は、GRAW を使用します。

  • 読み取り専用クエリがグローバルな一貫性ではなく、データの可視性を重視する場合は、GRAW を使用するか、各読み取りの前に待機時間を導入します。たとえば、単一のアプリケーションスレッドで 2 つの異なるノードへの接続 C1 および C2 を維持する場合があります。アプリケーションは C1 で書き込み、C2 で読み取ります。このような場合、アプリケーションは GRAW を使用してすぐに読み取りを発行するか、スリープしてから読み取りを発行します。スリープ時間はレプリケーションラグ (通常は約 20〜30 ミリ秒) 以上にする必要があります。

書き込み後の読み取り機能は、aurora_mm_session_consistency_level セッション変数を使用して制御されます。有効な値は、ローカル整合性モードの場合は INSTANCE_RAW (デフォルト)、クラスター全体の整合性の場合は REGIONAL_RAW です。

マルチマスタークラスターで DDL オペレーションを実行する

SQL データ定義言語 (DDL) ステートメントには、マルチマスタークラスターに関する特別な考慮事項があります。これらのステートメントによって、基礎となるデータを大幅に再編成する必要が生じる場合があります。このような大規模な変更が原因で、共有ストレージボリューム内の多くのデータページに影響を及ぼす可能性があります。テーブルおよびその他のスキーマオブジェクトの定義は、INFORMATION_SCHEMA テーブルに保持されます。 Aurora では、これらのテーブルへの変更を特別に処理して、複数の DB インスタンスが同時に DDL ステートメントを実行する場合の書き込みの競合を回避します。

DDL ステートメントの場合、Aurora はステートメント処理をクラスター内の特別なサーバープロセスに自動的に委任します。Aurora では INFORMATION_SCHEMA テーブルへの変更を一元化しているため、このメカニズムによって、DDL ステートメント間の書き込み競合が生じる可能性を抑えることができます。

DDL オペレーションによって、そのテーブルへの同時書き込みを防ぐことができます。テーブルでの DDL オペレーション中、マルチマスタークラスター内の DB インスタンスは、DDL ステートメントが終了するまで、そのテーブルに対して読み取り専用アクセスに制限されます。

次の DDL の動作は、Aurora シングルマスタークラスターとマルチマスタークラスターで同じです。

  • 1 つの DB インスタンスで DDL を実行すると、他のインスタンスはテーブルを使用してアクティブに接続を終了します。

  • セッションレベルの一時テーブルは、MyISAM または MEMORY のストレージエンジンを使用して、任意のノードで作成できます。

  • DB インスタンスに十分なローカル一時ストレージがないと、非常に大きなテーブルでの DDL オペレーションでエラーになる可能性があります。

マルチマスタークラスターでの次の DDL パフォーマンスの考慮事項に注意してください。

  • アプリケーションで多数の短い DDL ステートメントを発行しないようにしてください。可能な場合は、事前にデータベース、テーブル、パーティション、列などを作成します。レプリケーションのオーバーヘッドにより、一般的に非常に高速な単純な DDL ステートメントのパフォーマンスで大きなオーバーヘッドが発生する場合があります。ステートメントは、変更がクラスター内のすべての DB インスタンスにレプリケートされるまで終了しません。たとえば、マルチマスタークラスターでは、空のテーブルの作成、テーブルの削除、または多くのテーブルを含むスキーマの削除で、他の Aurora クラスターよりも時間がかかります。

    大量の DDL オペレーションを実行する必要がある場合は、複数のスレッドを介してステートメントを並列に発行することにより、ネットワークと調整のオーバーヘッドを削減できます。

  • レプリケーションの遅延は DDL ステートメントの合計時間のほんの一部であるため、長時間実行される DDL ステートメントへの影響は小さくなります。

  • セッションレベルの一時テーブルでの DDL のパフォーマンスは、Aurora シングルマスタークラスターとマルチマスタークラスターでほぼ同等である必要があります。一時テーブルのオペレーションはローカルで行われるため、同期レプリケーションのオーバーヘッドの影響を受けません。

マルチマスタークラスターでの Percona Online Schema Change の使用

pt-online-schema-change ツールは、マルチマスタークラスターで動作します。この方法は、最も高い非ブロック方式でテーブル変更を実行することを優先する場合に使用できます。ただし、スキーマ変更プロセスの書き込み競合の影響に注意してください。

概要レベルでは、pt-online-schema-change ツールは次のように機能します。

  1. 目的の構造を持つ空のテーブルを新しく作成します。

  2. 元のテーブルに DELETEINSERT、および UPDATE のトリガーを作成して、新しいテーブルの上部にある元のテーブルのデータ変更を再実行します。

  3. 既存の行が小さなチャンクを使用して新しいテーブルに移動するのに対し、進行中のテーブルの変更はトリガーを使用して自動的に処理されます。

  4. すべてのデータが移動されたら、トリガーを削除し、それらの名前を変更してテーブルを切り替えます。

潜在的な競合ポイントは、データが新しいテーブルに転送されている間に発生します。最初に作成される新しいテーブルは完全に空であるため、ロックのホットポイントになる可能性があります。他の種類のデータベースシステムでも同じことが言えます。トリガーは同期的であるため、ホットポイントからの影響がクエリに反映される可能性があります。

マルチマスタークラスターでは、影響をより明確にすることができます。この可視性は、新しいテーブルがロックの競合を引き起こすだけでなく、書き込みの競合の可能性を高めるためです。テーブルの最初のページはごくわずかです。つまり、書き込みは高度にローカライズされているため、競合が発生しやすくなります。テーブルが大きくなると、書き込みは広がるため、書き込みの競合の問題は解消されます。

マルチマスタークラスターでオンラインスキーマ変更ツールを使用できます。ただし、より慎重なテストを行う必要があり、進行中のワークロードへの影響は、操作の最初の数分でわずかに見える可能性があります。

自動インクリメント列の使用

Aurora マルチマスタークラスターは、既存の設定パラメータ auto_increment_increment および auto_increment_offset を使用して自動インクリメント列を処理します。詳細については、「MySQL リファレンスマニュアル」を参照してください。

パラメータ値は事前に決められているため、変更することはできません。具体的には、auto_increment_increment パラメータは 16 にハードコードされています。これは、あらゆる種類のクラスターの Aurora DBインスタンスの最大数です。

ハードコードされた増分設定により、自動増分の値はシングルマスタークラスターよりもはるかに速く消費されます。これは、特定のテーブルが単一の DB インスタンスによってのみ変更される場合でも同じです。最良の結果を得るには、自動インクリメント列に常に INT ではなく BIGINT データ型を使用してください。

マルチマスタークラスターでは、次のプロパティを持つ自動インクリメント列を許容するようにアプリケーションロジックを準備する必要があります。

  • 値は連続的ではありません。

  • 空のテーブルでは、値が 1 から開始されない場合があります。

  • 値は 1 より大きい増分で増加します。

  • 値は、シングルマスタークラスターよりもはるかに速く消費されます。

次の例は、マルチマスタークラスター内の自動インクリメント値のシーケンスが、予想とは異なる場合があることを示しています。

mysql> create table autoinc (id bigint not null auto_increment, s varchar(64), primary key (id)); mysql> insert into autoinc (s) values ('row 1'), ('row 2'), ('row 3'); Query OK, 3 rows affected (0.02 sec) mysql> select * from autoinc order by id; +----+-------+ | id | s | +----+-------+ | 2 | row 1 | | 18 | row 2 | | 34 | row 3 | +----+-------+ 3 rows in set (0.00 sec)

AUTO_INCREMENT テーブルのプロパティは変更することができます。デフォルト以外の値の使用は、その値がすでにテーブルにある主キー値のいずれよりも大きい場合にのみ確実に機能します。テーブルの空の間隔を埋めるために小さい値を使用することはできません。変更すると、変更は一時的に有効になるか、まったく有効になりません。この動作は MySQL 5.6 から継承され、Aurora の実装に固有のものではありません。

マルチマスタークラスター機能のリファレンス

以下に、Aurora マルチマスタークラスターに固有のコマンド、手順、およびステータス変数のクイックリファレンスを示します。

書き込み後読み取り (Read-After-Write) の使用

書き込み後の読み取り機能は、aurora_mm_session_consistency_level セッション変数を使用して制御されます。有効な値は、ローカル整合性モードの場合は INSTANCE_RAW (デフォルト)、クラスター全体の整合性の場合は REGIONAL_RAW です。

以下に例を示します。

mysql> select @@aurora_mm_session_consistency_level; +---------------------------------------+ | @@aurora_mm_session_consistency_level | +---------------------------------------+ | INSTANCE_RAW                          | +---------------------------------------+ 1 row in set (0.01 sec) mysql> set session aurora_mm_session_consistency_level = 'REGIONAL_RAW'; Query OK, 0 rows affected (0.00 sec) mysql> select @@aurora_mm_session_consistency_level; +---------------------------------------+ | @@aurora_mm_session_consistency_level | +---------------------------------------+ | REGIONAL_RAW                          | +---------------------------------------+ 1 row in set (0.03 sec)

DB インスタンスの読み書きモードを確認する

マルチマスタークラスターでは、ノードはすべて、読み書きモードで動作します。innodb_read_only 変数では常に 0 が返ります。次の例は、マルチマスタークラスターの DB インスタンスに接続すると、DB インスタンスによって、読み書き機能があることがレポートされることを示しています。

$ mysql -h mysql -A -h multi-master-instance-1.example123.us-east-1.rds.amazonaws.com mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 0 | +--------------------+ mysql> quit; Bye $ mysql -h mysql -A -h multi-master-instance-2.example123.us-east-1.rds.amazonaws.com mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 0 | +--------------------+

ノード名とロールの確認

ステータス変数 aurora_server_id を使用して、現在接続している DB インスタンスの名前を確認できます。 その方法例は次のとおりです。

mysql> select @@aurora_server_id; +----------------------+ | @@aurora_server_id   | +----------------------+ | mmr-demo-test-mm-3-1 | +----------------------+ 1 row in set (0.00 sec)

マルチマスタークラスター内のすべての DB インスタンスに関するこの情報については、クラスタートポロジを指定する を参照してください。

クラスタートポロジを指定する

マルチマスタークラスタートポロジを指定するには、information_schema.replica_host_status テーブルから選択します。マルチマスタークラスターとシングルマスタークラスターは、次の点で異なります。

  • has_primary 列は、ノードのロールを特定します。マルチマスタークラスターの場合、この値はすべての DDL および DCL ステートメントを処理する DB インスタンスにも当てはまります。 Aurora は、そのようなリクエストをマルチマスタークラスターの DB インスタンスの 1 つに転送します。

  • この replica_lag_in_milliseconds 列は、すべての DB インスタンスのレプリケーションラグをレポートします。

  • last_reported_status 列は、DB インスタンスのステータスをレポートします。OnlineRecoveryOffline のいずれかを設定できます。

以下に例を示します。

mysql> select server_id, has_primary, replica_lag_in_milliseconds, last_reported_status    -> from information_schema.replica_host_status; +----------------------+-------------+-----------------------------+----------------------+ | server_id            | has_primary | replica_lag_in_milliseconds | last_reported_status | +----------------------+------------------+------------------------+----------------------+ | mmr-demo-test-mm-3-1 | true    |               37.302 | Online | | mmr-demo-test-mm-3-2 | false |              39.907 | Online | +----------------------+-------------+-----------------------------+----------------------+

インスタンスの読み取り専用モードを使用する

Aurora マルチマスタークラスターでは、通常、関連するテーブルで書き込みオペレーションを実行する特定の DB インスタンスに SELECT ステートメントを発行します。これにより、レプリケーションラグによる一貫性の問題が回避され、バッファプールからのテーブルおよびインデックスデータの再利用が最大化されます。

クエリ重視のワークロードを複数のテーブルで実行する必要がある場合、マルチマスタークラスター内の 1 つ以上の DB インスタンスを読み取り専用として指定できます。

実行時に DB インスタンス全体を読み取り専用モードにするには、mysql.rds_set_read_only ストアドプロシージャを呼び出します。

mysql> select @@read_only; +-------------+ | @@read_only | +-------------+ |           0 | +-------------+ 1 row in set (0.00 sec) mysql> call mysql.rds_set_read_only(1); Query OK, 0 rows affected (0.00 sec) mysql> select @@read_only; +-------------+ | @@read_only | +-------------+ |           1 | +-------------+ 1 row in set (0.00 sec) mysql> call mysql.rds_set_read_only(0); Query OK, 0 rows affected (0.00 sec) mysql> select @@read_only; +-------------+ | @@read_only | +-------------+ |           0 | +-------------+ 1 row in set (0.00 sec)

ストアドプロシージャを呼び出すことは、SET GLOBAL read_only = 0|1 を実行することと同じです。この設定は実行時のみであり、エンジンの再起動後は維持されません。DB インスタンスを永続的に読み取り専用に設定するには、DB インスタンスのパラメータグループで read_only パラメータを true に設定します。

Aurora マルチマスタークラスターのパフォーマンスに関する考慮事項

シングルマスタークラスターとマルチマスタークラスターの両方で、Aurora エンジンは OLTP ワークロード向けに最適化されています。OLTP アプリケーションの大部分は、選択性の高いランダムアクセスクエリを備えた短期間のトランザクションで構成されています。このような多くのオペレーションを同時に実行するワークロードでは、Aurora から最大の利点を得ることができます。

常に 100% の使用率で実行しないようにしてください。これにより、Aurora の内部のメンテナンス作業に遅れが出ることはありません。マルチマスタークラスターのビジー状態と必要なメンテナンス作業の量を測定する方法については、Aurora マルチマスタークラスターのモニタリング を参照してください。

マルチマスタークラスターのクエリパフォーマンス

マルチマスタークラスターは、読み取り専用ノードまたは読み取り専用 DNS エンドポイントを提供しませんが、読み取り専用 DB インスタンスのグループを作成し、それらを目的に使用することができます。詳細については、「インスタンスの読み取り専用モードを使用する」を参照してください。

以下のアプローチを使用して、マルチマスタークラスターのクエリパフォーマンスを最適化できます。

  • クエリに関連するテーブル、データベース、またはその他のスキーマオブジェクトを含むシャードを処理する DB インスタンスで SELECT ステートメントを実行します。この方法により、バッファプール内のデータを最大限に再利用することができます。また、同じデータが複数の DB インスタンスにキャッシュされるのを防ぎます。この技術の詳細については、バッファプールとディクショナリキャッシュ使用の最適化 を参照してください。

  • 読み書きワークロードの分離が必要な場合は、インスタンスの読み取り専用モードを使用する で説明されているように、1 つ以上の DB インスタンスを読み取り専用として指定します。これらの DB インスタンスに読み取り専用セッションをダイレクトするには、対応するインスタンスエンドポイントに接続するか、すべての読み取り専用インスタンスに関連付けられているカスタムエンドポイントを定義します。

  • すべての DB インスタンスに読み取り専用クエリを展開します。このアプローチは、最も効率的の低い方法です。特に開発およびテスト段階から本番に移行する場合は、実用的な他のいずれかのアプローチを使用してください。

マルチマスタークラスターの競合解決

マルチマスタークラスターの多くのベストプラクティスでは、書き込みの競合の可能性を抑えることに重点を置いています。書き込みの競合を解決するには、ネットワークのオーバーヘッドが伴います。また、アプリケーションではエラー状態を処理し、トランザクションを再試行する必要があります。可能な限り、このような望ましくない結果を最小限に抑えるようにしてください。

  • また、同じ DB インスタンスを使用して特定のテーブルとそれに関連付けられたインデックスにすべての変更を加えます。1 つの DB インスタンスのみでデータページを変更する場合、そのページを変更しても書き込みの競合はトリガーできません。このアクセスパターンは、シャードまたはマルチテナントのデータベース展開で一般的です。このように、このようなデプロイを切り替えてマルチマスタークラスターを使用するのは比較的簡単です。

  • マルチマスタークラスターにはリーダーエンドポイントがありません。リーダーエンドポイントでは着信接続が負荷分散されるため、特定の接続を処理している DB インスタンスを認識する必要がありません。マルチマスタークラスターで接続を管理するには、各接続に使用される DB インスタンスを認識する必要があります。これにより、特定のデータベースまたはテーブルへの変更を常に同じ DB インスタンスにルーティングできます。

  • 少量のデータ (1 つの 16 KBページ) の書き込み競合により、トランザクション全体をロールバックするために大量の作業がトリガーされる可能性があります。そのため、理想的には、マルチマスタークラスターのトランザクションを比較的短く、小さく保つ必要があります。OLTP アプリケーションのこのベストプラクティスは、Aurora マルチマスタークラスターにとって特に重要です。

競合はページレベルで検出されます。異なる DB インスタンスから提案された変更がページ内の異なる行を変更するため、競合が発生する可能性があります。システムに導入されたページ変更はすべて、競合検出の対象です。このルールは、ソースがユーザートランザクションかサーバーバックグラウンドプロセスかに関係なく適用されます。また、データページがテーブル、セカンダリインデックス、UNDO スペースなどからのものであるかどうかにも適用されます。

各 DB インスタンスで一連のスキーマオブジェクトのすべての書き込みオペレーションが処理されるように、書き込みオペレーションを分割できます。この場合、各データページに対する変更はすべて、1 つの特定のインスタンスによって行われます。

バッファプールとディクショナリキャッシュ使用の最適化

マルチマスタークラスター内の各 DB インスタンスは、バッファプール、テーブルハンドラキャッシュ、テーブルディクショナリキャッシュなどのメモリ内バッファとキャッシュを個別に保持します。DB インスタンスごとに、バッファとキャッシュの内容と割合は、そのインスタンスで処理される SQL ステートメントに依存します。

メモリを効率的に使用すると、マルチマスタークラスターのパフォーマンスが向上し、I/O コストが削減されます。シャード設計を使用して、データを物理的に分離し、特定の DB インスタンスから各シャードに書き込みます。これにより、各 DB インスタンスのバッファキャッシュが最も効率的に使用されます。テーブルの SELECT ステートメントを、そのテーブルの書き込みオペレーションを実行するのと同じ DB インスタンスに割り当ててみてください。そうすることで、これらのクエリがその DB インスタンスのキャッシュデータを再利用するのに役立ちます。多数のテーブルまたはパーティションがある場合、この方法により、各 DB インスタンスによってメモリに保持される一意のテーブルハンドラおよびディクショナリオブジェクトの数も削減されます。

Aurora マルチマスタークラスターへのアプローチ

次のセクションでは、マルチマスタークラスターに適した特定のデプロイに使用するアプローチについて説明します。これらのアプローチには、DB インスタンスがオーバーラップしないデータの部分に対して書き込みオペレーションを実行するように、ワークロードを分割する方法が含まれます。その結果、書き込みの競合が生じる可能性が最小限に抑えられます。書き込みの競合は、マルチマスタークラスターのパフォーマンスチューニングとトラブルシューティングの主な焦点です。

シャードデータベースでマルチマスタークラスターを使用する

シャーディングは、Aurora マルチマスタークラスターで適切に機能する一般的なタイプのスキーマ設計です。シャードアーキテクチャでは、各 DBインスタンスが割り当てられ、スキーマオブジェクトの特定のグループが更新されます。これにより、複数の DB インスタンスで、同時変更による競合なしに同じ共有ストレージボリュームに書き込むことができます。DB インスタンスごとに、複数のシャードの書き込みオペレーションを処理できます。DB インスタンスのシャードへのマッピングは、アプリケーション設定を更新して、いつでも変更することができます。データベースストレージを再編成したり、DB インスタンスを再構成する必要はありません。

一例として、分割されたスキーマ設計を使用するアプリケーションは、Aurora マルチマスタークラスターで使用するのに適しています。シャードシステムでデータを物理的に分割する方法は、書き込みの競合を回避するのに役立ちます。各シャードをパーティション、テーブル、データベースなどのスキーマオブジェクトにマップします。アプリケーションは、特定のシャードに対するすべての書き込みオペレーションを適切な DB インスタンスに送信します。

Bring-your-own-shard (BYOS) は、既にシャード/パーティション化されたデータベースとそれにアクセスできるアプリケーションがあるユースケースを示します。シャードはすでに物理的に分離されています。そのため、スキーマ設計を変更することなく、ワークロードを Aurora マルチマスタークラスターに簡単に移動することができます。同一のシンプルな移行パスがマルチテナントデータベースに適用されます。ここで、各テナントでは、専用テーブル、テーブルセット、またはデータベース全体を使用します。

シャードまたはテナントを 1 対 1 または多対 1 の方法で DB インスタンスにマッピングします。DB インスタンスごとに 1 つ以上のシャードが処理されます。シャードされた設計は、主に書き込みオペレーションに適用されます。同等のパフォーマンスを持つ DB インスタンスのシャードに対して SELECT クエリを発行できます。

時間が経つにつれて、シャードの 1 つがよりアクティブになったとします。ワークロードのバランスを取り直すために、そのシャードを担当する DB インスタンスを切り替えることができます。非 Aurora システムでは、データを別のサーバーに物理的に移動する必要がある場合があります。Aurora マルチマスタークラスターでは、シャードに対するすべての書き込みオペレーションを、未使用のコンピューティングキャパシティーを持つ他の DB インスタンスに向けることで、このようにリシャーディングできます。Aurora 共有ストレージモデルにより、データを物理的に再編成する必要がなくなります。

マルチマスタークラスターを使用する (シャーディングなし)

スキーマ設計で、データベース、テーブル、パーティションなどの物理的に分離されたコンテナーにデータを再分割しない場合でも、マルチマスタークラスターで使用できます。

パフォーマンスのオーバーヘッドが発生する可能性があります。また、書き込みの競合がデッドロック状態として扱われる場合、アプリケーションでトランザクションのロールバックが発生する場合があります。書き込み競合は、小さなテーブルの書き込みオペレーション中に発生する可能性が高くなります。テーブルに含まれるデータページが少ない場合は、プライマリキー範囲の異なる部分の行が同じデータページにある可能性があります。これらの行が異なる DB インスタンスによって同時に変更されると、このオーバーラップにより書き込みの競合が発生する可能性があります。

この場合、セカンダリインデックスの数も最小限に抑える必要があります。テーブルのインデックス付き列に変更を加えると、Aurora は関連するセカンダリインデックスに対応する変更を加えます。セカンダリインデックスと関連するテーブルでは行の順序とグループ化が異なるため、インデックスを変更すると書き込みの競合が発生する可能性があります。

この方法を使用すると、書き込みの競合が発生する可能性があるため、可能な場合は別のアプローチを使用することをお勧めします。データを異なるスキーマオブジェクトに再分割する代替データベース設計を使用できるかどうかを確認します。

マルチマスタークラスターをアクティブスタンバイとして使用する

アクティブスタンバイとは、別の DB インスタンスと同期を維持している DB インスタンスであり、非常に迅速に引き継ぐことができます。この構成は、単一の DB インスタンスがワークロード全体を処理できる状況での高可用性に役立ちます。

読み書きと読み取り専用のすべてのトラフィックを単一の DB インスタンスに転送することにより、アクティブスタンバイ構成でマルチマスタークラスターを使用できます。その DB インスタンスが利用できなくなった場合、アプリケーションは問題を検出し、すべての接続を別の DB インスタンスに切り替える必要があります。この場合、他の DB インスタンスで読み書き接続を受け入れられるため、Aurora ではフェイルオーバーは実行されません。一度に 1 つの DB インスタンスにのみ書き込むことで、書き込みの競合を回避できます。そのため、この方法でマルチマスタークラスターを使用するために、分割されたデータベーススキーマを持つ必要はありません。

ヒント

アプリケーションで短い一時停止が可能な場合は、DB インスタンスが使用できなくなった後、数秒待ってから、書き込みトラフィックを別のインスタンスにリダイレクトできます。再起動によりインスタンスが使用できなくなっても、約 10~20 秒後に再び使用可能になります。インスタンスをすぐに再起動できないと、Aurora はそのインスタンスの復元を開始する場合があります。インスタンスがシャットダウンされると、シャットダウンの一部として追加のクリーンアップアクティビティが実行されます。インスタンスの再起動中、リカバリ中、またはシャットダウン中に別のインスタンスへの書き込みを開始すると、書き込みの競合が発生する可能性があります。競合は、新しいインスタンスの SQL ステートメントと、再起動またはシャットダウンされたインスタンスのロールバックやパージなどの復元オペレーションの間で発生する可能性があります。