今日はなにの日。

気になったこと勉強になったことのメモ。

トップ > AWS > 今日は、DBSに向けたAurora まとめの日。

今日は、DBSに向けたAurora まとめの日。

AWS AWS資格勉強用 データベース

目次

とある日

AWS DBSの勉強用の記録。

Auroraのキーワードを調べてまとめる。

コンポーネント

  • プライマリDBインスタンス
    • 読み書きオペレーションをサポートし、クラスターボリュームに対するすべてのデータ変更を実行します。各 Aurora DB クラスターには 1 つのプライマリ DB インスタンスがあります。
  • Auroraレプリカ
    • プライマリ DB インスタンスと同じストレージボリュームに接続し、読み取りオペレーションのみをサポートします。各 Aurora DB クラスターは、プライマリ DB インスタンスに加えて 15 Aurora までのレプリカを持つことができます。Aurora レプリカを複数のアベイラビリティーゾーンに配置することで、高可用性を維持します。Aurora は、プライマリ DB インスタンスが使用できなくなった場合に自動的に Aurora レプリカにフェイルオーバーします。Aurora レプリカのフェイルオーバー優先順位を指定することができます。また、Aurora レプリカは、プライマリ DB インスタンスから読み取りワークロードをオフロードします。
  • クラスタボリューム
  • AuroraDBクラスター
  • Auroraエンドポイント
    • エンドポイントは、ホストアドレスとポートを含む Aurora 固有の URL として表されます。

Amazon Aurora DB クラスター - Amazon Aurora

Amazon Aurora DB クラスターの作成 - Amazon Aurora

Aurora エンドポイント

Amazon Aurora 接続管理 - Amazon Aurora

タイプ

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

Aurora DB クラスターのクラスターエンドポイント (またはライターエンドポイント) は、その DB クラスターの現在のプライマリ DB インスタンスに接続します。このエンドポイントは、DDL ステートメントなどの書き込みオペレーションを実行できる唯一のエンドポイントです。このため、初期にクラスターを設定する場合や、クラスターに含まれている DB インスタンスが 1 つのみである場合は、クラスターエンドポイントに接続します。

Aurora DB クラスターごとに 1 つのクラスターエンドポイントと 1 つのプライマリ DB インスタンスがあります。

クラスターエンドポイントは、DB クラスターに対するすべての書き込みオペレーション (挿入、更新、削除、DDL の変更など) で使用します。クラスターエンドポイントは、クエリなどの読み取りオペレーションでも使用できます。

クラスターエンドポイントは、DB クラスターへの読み取り/書き込み接続のフェイルオーバーサポートを提供します。DB クラスターの現在のプライマリ DB インスタンスが失敗した場合、Aurora は新しいプライマリ DB インスタンスに自動的にフェイルオーバーします。フェイルオーバー中、DB クラスターは、新しいプライマリ DB インスタンスからクラスターエンドポイントへの接続リクエストに継続して対応し、サービスの中断は最小限に抑えられます。

次の例では、Aurora MySQL DB クラスターのエンドポイントを示します。

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

リーダーエンドポイント

Aurora DB クラスターのリーダーエンドポイントは、その DB クラスターへの読み取り専用接続を負荷分散します。リーダーエンドポイントは、クエリなどの読み取りオペレーションで使用します。これらのステートメントを読み取り専用の Aurora レプリカで処理することにより、このエンドポイントはプライマリインスタンスのオーバーヘッドを削減します。また、クラスター内の Aurora レプリカの数に合わせて、同時 SELECT クエリを処理する容量をスケールすることもできます。Aurora DB クラスターごとに 1 つのリーダーエンドポイントがあります。

クラスターに 1 つ以上の Aurora レプリカが含まれている場合、リーダーエンドポイントは Aurora レプリカ間で各接続リクエストを負荷分散します。その場合、そのセッションでは SELECT などの読み取り専用ステートメントのみを実行できます。クラスターにプライマリインスタンスのみが含まれていて、Aurora レプリカが含まれていない場合、リーダーエンドポイントはプライマリインスタンスに接続します。その場合は、エンドポイントを介して書き込みオペレ―ションを実行できます。

次の例では、Aurora MySQL DB クラスターのリーダーエンドポイントを示します。

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

カスタムエンドポイント

Aurora クラスターのカスタムエンドポイントは、選択した DB インスタンスのセットを表します。カスタムエンドポイントに接続すると、Aurora は負荷分散を行い、グループ内のいずれかのインスタンスを選択して接続を処理します。ユーザーは、このエンドポイントで参照するインスタンスを定義し、エンドポイントの用途を決めます。

Aurora DB クラスターには、ユーザーが作成するまで、カスタムエンドポイントは存在しません。Aurora のプロビジョニングされたクラスターごとに最大 5 つのカスタムエンドポイントを作成できます。Aurora Serverless クラスターにカスタムエンドポイントを使用することはできません。

カスタムエンドポイントでは、DB インスタンスの読み取り専用機能や読み取り/書き込み機能とは異なる基準に従ってデータベース接続を負荷分散できます。例えば、特定の AWS インスタンスクラスや特定の DB パラメータグループを使用するインスタンスに接続するカスタムエンドポイントを定義できます。次に、このカスタムエンドポイントを特定のユーザーグループに知らせることができます。例えば、社内ユーザーをレポート生成やアドホック (1 回だけの) クエリ実行用の低容量インスタンスに振り向けたり、本番稼働用トラフィックを高容量インスタンスに振り向けたりすることができます。

カスタムエンドポイントが関連付けられているいずれの DB インスタンスも接続先となるため、グループ内のすべての DB インスタンス間で同様の特性を共有することをお勧めします。これにより、このエンドポイントに接続するすべてのユーザー間で、パフォーマンス、メモリ容量などが一貫したものになります。

この機能は、クラスター内のすべての Aurora レプリカを同一に保つことが現実的ではない特種なワークロードを扱う上級ユーザー向けです。カスタムエンドポイントを使用すると、各接続に使用される DB インスタンスの容量を予測できます。カスタムエンドポイントを使用する場合は、通常、そのクラスターのリーダーエンドポイントは使用しません。

次の例は、Aurora MySQL DB クラスター内の DB インスタンスのカスタムエンドポイントを示しています。

myendpoint.cluster-custom-123456789012.us-east-1.rds.amazonaws.com:3306

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

インスタンスエンドポイントは、Aurora クラスター内の特定の DB インスタンスに接続します。DB クラスターの各 DB インスタンスには、独自のインスタンスエンドポイントがあります。したがって、DB クラスター内の現在のプライマリ DB インスタンスに 1 つのインスタンスエンドポイントがあり、DB クラスター内の Aurora レプリカごとに 1 つのインスタンスエンドポイントがあります。

インスタンスエンドポイントは、クラスターエンドポイントやリーダーエンドポイントの使用が適切でないシナリオ向けに、DB クラスターへの接続の直接制御を提供します。例えば、ワークロードタイプに基づき、さらにきめ細かいロードバランシングがアプリケーションに必要になる場合があります。この場合、DB クラスター内の別の Aurora レプリカに接続するように複数のクライアントを設定して、読み取りワークロードを分散させることができます。Aurora PostgreSQL のフェイルオーバー後に接続速度を向上させるインスタンスエンドポイントを使用する例については、「Amazon Aurora PostgreSQL による高速フェイルオーバー」を参照してください。Aurora MySQL のフェイルオーバー後にインスタンスエンドポイントを使用して接続速度を向上させる例については、MariaDB Connector/J failover support - case Amazon Aurora を参照してください。

次の例では、Aurora MySQL DB クラスターの DB インスタンスのインスタンスエンドポイントを示します。

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

レプリカ優先度

各レプリカに優先度を割り当てることで、Aurora レプリカがプライマリインスタンスに昇格される順序をカスタマイズできます。優先度の範囲は、最も高い 0 から最も低い 15 までです。プライマリインスタンスが失敗した場合、Amazon RDS は優先度が高い Aurora レプリカを新しいプライマリインスタンスに昇格します。Aurora レプリカの優先度はいつでも変更できます。優先度を変更しても、フェイルオーバーはトリガーされません。

Amazon Aurora の高可用性 - Amazon Aurora

複数の Aurora レプリカで同じ優先度を共有でき、その場合は昇格階層が発生します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

[新機能]RDS for Auroraでフェイルオーバー先の優先順序を指定できます | DevelopersIO

クラスターキャッシュ機能

フェイルオーバーが発生した場合に Aurora PostgreSQL クラスター内の書き込み DB インスタンスを迅速にリカバリするには、Amazon Aurora PostgreSQL のクラスターキャッシュ管理を使用します。クラスターキャッシュ管理を使用することで、フェイルオーバー発生時でもアプリケーションパフォーマンスを維持することができます。

Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ - Amazon Aurora

グローバルデータベース

Amazon Aurora Global Database は複数の AWS リージョン にまたがり配置されます。これにより、低レイテンシーのグローバル読み取りを実現し、AWS リージョン 全体に影響が及ぶ可能性のある停止がまれに起きても、すばやい復旧を可能にします。Aurora Global Database には、1 つのリージョンにプライマリ DB クラスターがあり、異なるリージョンに最大 5 つのセカンダリ DB クラスターがあります。

Amazon Aurora Global Database の使用 - Amazon Aurora

利点

  • ローカルのレイテンシーによるグローバルな読み取り – 世界中にオフィスを持つ企業は、Aurora Global Database を使用することで、プライマリ AWS リージョン にある自社の主要な情報源を最新状態に保つことができます。他のリージョンにあるオフィスは、自社のリージョンにある情報にローカルのレイテンシーでアクセスすることができます。
  • スケーラブルなセカンダリ Aurora DB クラスター – セカンダリクラスターは、読み取り専用のインスタンス (Aurora レプリカ) をセカンダリ AWS リージョン にさらに追加することでスケールできます。セカンダリクラスターは読み取り専用です。したがって、読み取り専用の Aurora レプリカインスタンスを、1 つの Aurora クラスターにつき、通常の 15 件ではなく最大 16 件サポートします。
  • プライマリからセカンダリの Aurora DB クラスターへの迅速なレプリケーション-Aurora Global Database によるレプリケーションは、プライマリ DB クラスターのパフォーマンスにほとんど影響しません。DB インスタンスのリソースは、全面的にアプリケーションの読み取りおよび書き込みワークロードに当てられます。
  • リージョン全体にわたる停止からの回復 – セカンダリクラスターを使用すると、従来のレプリケーションソリューションと比較して迅速 (低い RTO) かつ少ないデータ損失 (低い RPO) で、Aurora Global Database を新しいプライマリ AWS リージョン で使用できるようになります。

制限

クロスリージョンレプリケーション

Amazon Aurora MySQL DB クラスターを、出典 DB クラスターとは異なる AWS リージョンに、リードレプリカとして作成できます。このアプローチを使用すると、災害対策機能が向上し、ユーザーに近い AWS リージョンへの読み取りオペレーションをスケールして、AWS リージョン間の移行を容易にすることができます。

暗号化されている DB クラスターと暗号化されていない DB クラスターの両方のリードレプリカを作成できます。出典 DB クラスターが暗号化されている場合、リードレプリカを暗号化する必要があります。

注記

クロスリージョンリードレプリカの代わりに、 Aurora Global Database を使用して、最小限のラグタイムで読み取り操作をスケールできます。Aurora Global Database では、1 つの AWS リージョンにプライマリ Aurora DB クラスターがあり、異なるリージョンに最大 5 つの読み取り専用セカンダリ DB クラスターがあります。各セカンダリ DB クラスターには、最大 16 個の (15 ではなく) Aurora レプリカを含めることができます。プライマリ DB クラスターからすべてのセカンダリへのレプリケーションは、データベースエンジンではなく Aurora ストレージレイヤーによって処理されるため、変更をレプリケートする際のラグタイムは非常に短く、通常は 1 秒未満となります。データベースエンジンをレプリケーションプロセスから除外するということは、データベースエンジンがワークロードの処理のみを実行することを意味します。また、Aurora MySQL の binlog (バイナリログ) のレプリケーションを設定または管理する必要もありません。詳細については、「Amazon Aurora Global Database の使用」を参照してください。

AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケーション - Amazon Aurora

マルチマスタークラスター

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

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

利点

制限

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

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

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

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

    • US East (N. Virginia) Region
    • US East (Ohio) Region
    • 米国西部 (オレゴン) リージョン - 600
    • Asia Pacific (Mumbai) Region
    • Asia Pacific (Seoul) Region
    • アジアパシフィック (東京) リージョン
    • 欧州 (フランクフルト) リージョン
    • リージョン ‐ 欧州 (アイルランド)

  • 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 機能は、マルチマスタークラスターでは使用できません。

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

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

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

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

AutoScaling

接続およびワークロード要件を満たすために、Aurora Auto Scaling は、シングルマスターレプリケーションを使用して、Aurora DB クラスター用にプロビジョニングされた Aurora レプリカの数を動的に調整します。Aurora Auto Scaling は、Aurora MySQL と Aurora PostgreSQL の両方で使用できます。Aurora Auto Scaling により、お使いの Aurora DB クラスターは急激な接続やワークロードの増加を処理できます。接続やワークロードが減ると、Aurora Auto Scaling は未使用のプロビジョニングされた DB インスタンスに対する料金が発生しないように、不要な Aurora レプリカを削除します。

Aurora レプリカでの Amazon Aurora Auto Scaling の使用 - Amazon Aurora

Aurora Auto Scaling ポリシー

Aurora Auto Scaling はスケーリングポリシーを使用して、Aurora DB クラスターの Aurora レプリカ数を調整します。Aurora Auto Scaling には以下のコンポーネントがあります。

  • サービスにリンクされたロール
  • ターゲットメトリクス
  • 最小容量と最大容量
  • クールダウン期間

Serverless

Amazon Aurora Serverless v1 (Amazon Aurora サーバーレスバージョン 1) は、Amazon Aurora 用のオンデマンドオートスケーリング構成です。Aurora Serverless DB クラスターでは、クラスターのコンピューティング容量を、アプリケーションのニーズに対応して増減ささせられます。これは、ユーザーにより容量が手動で管理される、Aurora のプロビジョニングされた DB クラスターとは対照的です。Aurora Serverless v1 では、頻度が低く、断続的、または予測が困難なワークロードを処理するための、比較的シンプルかつコスト効率の高いオプションを提供しています。このコスト効率が良いのは、アプリケーションの使用状況に合わせて自動的に起動してコンピューティング性能をスケールし、不使用時にはシャットダウンするためです。

Amazon Aurora Serverless v1 の使用 - Amazon Aurora

利点

  • プロビジョニングよりもシンプル - Aurora Serverless v1 では、DB インスタンスや容量を管理する上での複雑さが、大幅に軽減されます。
  • スケーラブル - Aurora Serverless v1 は、必要に応じてシームレスにコンピューティング性能とメモリ容量をスケールします。これに伴うクライアント接続の中断はありません。
  • 高いコスト効率 - Aurora Serverless v1 の使用料金は、データベースリソースの秒単位の消費分に対してのみ発生します。
  • 可用性の高いストレージ - Aurora Serverless v1 では、Aurora と同じ 6 ウェイレプリケーションを使用した耐障害性の高い分散型ストレージシステムを使用することで、データを損失から守っています。

ユースケース

  • 利用頻度の低いアプリケーション - 1 日または週に数回、それぞれ数分のみ使用される (低ボリュームのブログサイトなどの) アプリケーション。Aurora Serverless v1 では、消費したデータベースリソース分のみの料金を、秒単位でお支払いいただきます。
  • 新しいアプリケーション - 現在デプロイ中で、必要とされるインスタンスサイズが明確でない、新しいアプリケーション。Aurora Serverless v1 を使用することで、データベースのエンドポイントが作成できます。データベースの容量は、アプリケーションの要件に応じて自動的にスケーリングされます。
  • 可変ワークロード - 使用時間のピークが 30 分～数時間ほどで、それが 1 日もしくは 1 年に数回発生するような、負荷が重くないアプリケーション。人事管理、予算作成、運営報告用のアプリケーションなどが該当します。Aurora Serverless v1 を導入することで、ピーク容量や平均容量に合わせてプロビジョニングする必要はなくなります。
  • 予測が困難なワークロード - 毎日実行され、突然、想定し得ないアクティビティの増加が発生するようなワークロード。雨が降り出したときにアクティビティが急増 (サージ) するトラフィックサイトなどが該当します。Aurora Serverless v1 では、アプリケーションのピーク時の負荷要件に合わせて、データベースの容量がオートスケーリングされ、アクティビティのサージが終了した時点でスケールバックされます。
  • 開発およびテスト中のデータベース - 勤務時間中にデベロッパーにより使用されるものの、夜間や週末には必要とされないデータベース。Aurora Serverless v1 では、使用されていないデータベースは、自動的にシャットダウンされます。
  • マルチテナントアプリケーション - Aurora Serverless v1 を使用することで、フリート内のアプリケーションごとのデータベース容量を、ユーザーが個別に管理する必要はなくなります。個々のデータベース容量は、Aurora Serverless v1 により自動的に管理されます。

クローン

Aurora クローン作成を使用すると、同じ Aurora クラスターボリュームを使用し、元のクラスターと同じデータを持つ新しいクラスターをすばやくコスト効率よく作成できます。関連付けられたデータボリュームを持つ新しいクラスターは、クローンと呼ばれます。クローンの作成は、スナップショットの復元など、他の手法を使用してデータを物理的にコピーするよりも、高速かつスペース効率に優れています。

Aurora DB クラスターのボリュームのクローン作成 - Amazon Aurora

制限

  • ソース Aurora DB クラスターとは異なる AWS リージョンにはクローンを作成できません。
  • 暗号化されていないプロビジョニングされた Aurora DB クラスターからは Aurora Serverless v1 クローンを作成できません。
  • MySQL 5.6 互換でプロビジョニングされたクラスターからは Aurora Serverless v1 クローンを作成できません。また、MySQL 5.6 互換 Aurora Serverless v1 クラスターのプロビジョニングされたクローンを作成することもできません。
  • 1 つのコピーまたは別のクローンに基づいて、15 個を超えるクローンを作成することはできません。15 個のクローンを作成した後は、コピーのみを作成できます。ただし、各コピーにつき最大 15 個のクローンを作成できます。
  • 並列クエリ機能なしの Aurora DB クラスターから、並列クエリを使用するクラスターにクローンを作成することはできません。並行クエリを使用するクラスターにデータを格納するには、元のクラスターのスナップショットを作成して、それを並行クエリ機能を使用するクラスターに復元します。
  • DB インスタンスを持たない Aurora DB クラスターからクローンを作成することはできません。少なくとも 1 つの DB インスタンスを持つ Aurora DB クラスターのクローン作成のみが可能です。
  • クローンは、Aurora DB クラスターとは異なる仮想プライベートクラウド (VPC) で作成できます。その場合、VPCのサブネットは同じアベイラビリティゾーンにマッピングする必要があります。

バックトラック

Amazon Aurora MySQL 互換エディション では、バックアップからデータを復元しないで、DB クラスターを特定の時刻までバックトラックできます。

Aurora DB クラスターのバックトラック - Amazon Aurora

バックトラックは、指定した時間まで DB クラスターを「巻き戻し」ます。バックトラックは、DB クラスターをバックアップして特定の時点の状態に復元する操作に代わるものではありません。

利点

  • 簡単にエラーを取り消すことができます。WHERE 句なしの DELETE などの破壊的なアクションを間違えて実行した場合、サービスの中断を最小限に抑えながら、破壊的なアクション以前の時点まで DB クラスターをバックトラックできます。
  • DB クラスターのバックトラックは迅速に実行できます。DB クラスターを特定の時点の状態に復元するには、新しい DB クラスターを起動し、これに対してバックアップデータや DB クラスターのスナップショットから復元する必要があり、時間がかかります。DB クラスターのバックトラックでは、新しい DB クラスターを作成せずに、DB クラスターを数分で巻き戻します。
  • 以前のデータの変更を調べることができます。DB クラスターを前後に繰り返しバックトラックして、特定のデータの変更がどの時点で発生したかを確認できます。例えば、DB クラスターを 3 時間前までバックトラックし、そこから 1 時間後まで戻すことができます。この場合、バックトラック時間は元の時間の 2 時間前となります。

障害挿入クエリ

障害挿入クエリを使用して、Amazon Aurora DB クラスターの耐障害性をテストできます。障害挿入クエリは、Amazon Aurora インスタンスに対して SQL コマンドとして発行され、次のいずれかのイベント発生をシミュレートしてスケジュールすることができます。

障害挿入クエリを使用した Amazon Aurora のテスト - Amazon Aurora

インスタンスのクラッシュのテスト

ALTER SYSTEM CRASH 障害挿入クエリを使用して、Amazon Aurora インスタンスのクラッシュを強制的に発生させることができます。

この障害挿入クエリでは、フェイルオーバーが発生しません。フェイルオーバーをテストする場合、RDS コンソールで DB クラスターの [Failover] (フェイルオーバー) インスタンスアクションを選択するか、AWS CLI コマンドの failover-db-cluster、または RDS API の FailoverDBCluster オペレーションを使用します。

構文

ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];

オプション

この障害挿入クエリでは、次のクラッシュタイプのいずれかを指定できます。

デフォルトのクラッシュタイプは INSTANCE です。

Aurora レプリカの障害のテスト

ALTER SYSTEM SIMULATE READ REPLICA FAILURE 障害挿入クエリを使用して、Aurora レプリカの障害をシミュレートできます。

Aurora レプリカの障害は、指定した期間で、Aurora レプリカまたは DB クラスター内のすべての Aurora レプリカに対するすべてのリクエストをブロックします。指定した期間が終了すると、影響を受けた Aurora レプリカは自動的にマスターインスタンスと同期されます。

構文

ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
    [ TO ALL | TO "replica name" ]
    FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリでは、以下のパラメータを使用します。

  • percentage_of_failure — 障害イベントの発生時にブロックするリクエストの割合です。この値は 0～100 の倍精度にすることができます。0 を指定すると、リクエストはブロックされません。100 を指定すると、すべてのリクエストがブロックされます。
  • 障害のタイプ — シミュレートする障害のタイプ。DB クラスター内のすべての Aurora レプリカの障害をシミュレートするには、TO ALL を指定します。1 つの Aurora レプリカの障害をシミュレートするには、TO と Aurora レプリカの名前を指定します。デフォルトの障害タイプは TO ALL です。
  • quantity — Aurora レプリカの障害のシミュレートにかかる時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。例えば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

ディスクの障害のテスト

ALTER SYSTEM SIMULATE DISK FAILURE 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。

ディスク障害のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントをエラーとしてマークします。シミュレーションの実行中、これらのセグメントに対するリクエストはブロックされます。

構文

ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
    [ IN DISK index | NODE index ]
    FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリでは、以下のパラメータを使用します。

  • percentage_of_failure — 障害イベントの発生時にエラーとしてマークするディスクの割合。この値は 0～100 の倍精度にすることができます。0 を指定すると、ディスクのどの部分もエラーとしてマークされません。100 を指定すると、ディスク全体がエラーとしてマークされます。
  • DISK index — 障害イベントをシミュレートする特定のデータの論理的なブロック。利用可能な論理的なデータブロックの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「Aurora MySQL DB クラスターのボリュームステータスの表示」を参照してください。
  • NODE index — 障害イベントをシミュレートする特定のストレージノード。利用可能なストレージノードの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「Aurora MySQL DB クラスターのボリュームステータスの表示」を参照してください。
  • quantity — ディスクの障害をシミュレートする時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。例えば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

ディスクの輻輳のテスト

ALTER SYSTEM SIMULATE DISK CONGESTION 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。

ディスク輻輳のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントを輻輳としてマークします。これらのセグメントに対するリクエストは、シミュレーションの実行中、指定した最小遅延値と最大遅延値の間で遅延します。

構文

ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
    BETWEEN minimum AND maximum MILLISECONDS
    [ IN DISK index | NODE index ]
    FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリでは、以下のパラメータを使用します。

  • percentage_of_failure —障害イベントの発生時に輻輳としてマークするディスクの割合です。この値は 0～100 の倍精度にすることができます。0 を指定すると、ディスクのどの部分も輻輳としてマークされません。100 を指定すると、ディスク全体が輻輳としてマークされます。
  • DISK index または NODE index — 障害イベントをシミュレートする特定のディスクまたはノード。ディスクまたはノードのインデックスの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。
  • minimum および maximum — 輻輳による遅延の最小値と最大値をミリ秒単位で指定します。シミュレーションの実行中、輻輳としてマークしたディスクセグメントでは、ミリ秒単位の最小値と最大値の間の範囲でランダムな遅延が発生します。
  • quantity — ディスクの輻輳のシミュレートにかかる時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した時間単位の期間だけ発生します。例えば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

データベースアクティビティストリーム

データベースアクティビティストリーミングを使用すると、データベースアクティビティのストリームをほぼリアルタイムでモニタリングできます。

データベースアクティビティストリーミングを使用した Amazon Aurora のモニタリング - Amazon Aurora

データベースアクティビティストリーミングの機能

Amazon Aurora は、アクティビティをほぼリアルタイムで Amazon Kinesis データストリームにプッシュします。Kinesis ストリーミングが自動的に作成されます。Kinesis から、Amazon Kinesis Data Firehose や AWS Lambda などの AWS サービスを設定して、ストリーミングを消費し、データを保存できます。

データベースアクティビティストリーミングの概要 - Amazon Aurora

データベースアクティビティストリーミングの非同期および同期モード

  • 非同期モード - データベースセッションでアクティビティストリーミングイベントが生成されると、セッションは直ちに通常のアクティビティに戻ります。アクティビティストリーミングイベントは、バックグラウンドで永続的なレコードになります。バックグラウンドタスクでエラーが発生した場合は、RDS イベントが送信されます。このイベントは、アクティビティストリーミングのイベントレコードが失われた可能性がある時間枠のスタートと終了を示します。

    非同期モードでは、アクティビティストリーミングの精度よりもデータベースのパフォーマンスが優先されます。

    注記

    非同期モードは、Aurora PostgreSQL と Aurora MySQL の両方で使用できます。

  • 同期モード - データベースセッションでアクティビティストリーミングイベントが生成されると、そのイベントが永続化されるまで、セッションによってその他のアクティビティはブロックされます。何らかの理由でイベントを永続化できない場合、データベースセッションは通常のアクティビティに戻ります。ただし、アクティビティストリーミングレコードがしばらくの間失われる可能性があることを示す RDS イベントが送信されます。システムが正常な状態に戻ったら、2 番目の RDS イベントが送信されます。

    同期モードでは、データベースパフォーマンスよりもアクティビティストリーミングの精度が優先されます。

    注記

    同期モードは、Aurora PostgreSQL で使用できます。Aurora MySQL では同期モードを使用できません。

対応バージョン

Aurora PostgreSQL では、以下のバー本のデータベースアクティビティストリーミングがサポートされています。

  • すべての 13 バージョン
  • すべての 12 バージョン
  • バージョン 11.6、バージョン 11 以降
  • バージョン 10.11、バージョン 10 以降

Aurora PostgreSQL のバージョンの詳細については、「Amazon Aurora PostgreSQL リリースとエンジンのバージョン」を参照してください。

Aurora MySQL の場合、データベースアクティビティストリーミングはバージョン 2.08 以上でサポートされています。このバージョンは MySQL バージョン 5.7 と互換性があります。