Amazon Aurora Global Database でスイッチオーバーまたはフェイルオーバーを使用する

Aurora グローバルデータベースは、単一の AWS リージョン で Aurora DB クラスターによって提供される標準高可用性よりも、事業継続性とディザスタリカバリ (BCDR) 保護を強化します。Aurora グローバルデータベースを使用すれば、実際の地域災害に備えて計画を立てて復旧したり、サービスレベルの停止を迅速に完了したりできます。災害からの復旧は、通常、次の 2 つのビジネス目標によって推進されます。

Aurora グローバルデータベースの切り替えまたはフェイルオーバーには、グローバルデータベースのセカンダリリージョンのいずれかにある DB クラスターをプライマリ DB クラスターに昇格させる必要があります。「リージョン障害」という用語は、さまざまな障害シナリオを表すためによく使用されます。最悪のシナリオとしては、数百平方マイルに及ぶ壊滅的な事象による広範囲にわたる停電が考えられます。しかし、ほとんどの停電ははるかに局所的で、影響を受けるのはクラウドサービスや顧客システムのごく一部に限られます。障害の全容を検討して、クロスリージョンフェイルオーバーが適切な解決策であることを確認し、状況に適したフェイルオーバー方法を選択してください。フェイルオーバーとスイッチオーバーのどちらを使用するかは、具体的な停止シナリオによって異なります。

予期しない停止からの Amazon Aurora Global Database の復旧

ごくまれに、Aurora Global Database のプライマリ AWS リージョン で予期しない停止が発生することがあります。この場合、プライマリ Aurora DB クラスターとその読み取りノードを使用できなくなり、プライマリとセカンダリ DB クラスター間のレプリケーションが停止します。ダウンタイム (RTO) とデータ損失 (RPO) の両方を最小限に抑えるため、迅速に作業を行ってリージョン間のフェイルオーバーを実行できます。

ディザスタリカバリ時のフェイルオーバーには 2 つの方法があります。

Aurora Global Database のマネージドフェイルオーバーを実行する

このアプローチは、真の地域災害やサービスレベルの全面的な停止が発生した場合でも事業を継続できるようにするためのものです。

マネージドフェイルオーバー中、プライマリクラスターは選択したセカンダリリージョンにフェイルオーバーされ、Aurora Global Database の既存のレプリケーショントポロジが維持されます。選択したセカンダリクラスターは、読み取り専用ノードの 1 つを完全な読み取り状態に昇格します。このステップにより、クラスターがプライマリクラスターのロールを引き受けることができます。クラスターが新しいロールを引き受ける間、データベースは短時間使用できなくなります。古いプライマリクラスターから選択したセカンダリクラスターにレプリケートされなかったデータは、このセカンダリクラスターが新しいプライマリクラスターになると失われます。

データの損失を最小限に抑えるため、この機能を使用する前に次のことを行うことをお勧めします。

マネージドフェイルオーバー中、選択したセカンダリ DB クラスターは、プライマリとして新しいロールに昇格されます。ただし、プライマリ DB クラスターのさまざまな設定オプションは継承されません。構成の不一致は、パフォーマンスの問題、ワークロードの非互換性、およびその他の異常な動作につながる可能性があります。このような問題を回避するには、Aurora Global Database クラスター間の次の違いを解決することをお勧めします。

通常、選択したセカンダリクラスターが数分以内に主要な役割を引き継ぎます。新しいプライマリリージョンのライターノードが使用可能になり次第、アプリケーションをそのライターノードに接続してワークロードを再開できます。Aurora が新しい主クラスターをプロモートすると、追加のセカンダリリージョンクラスターはすべて自動的に再構築されます。

Aurora グローバルデータベースは非同期レプリケーションを使用するため、各セカンダリリージョンのレプリケーションラグは異なる場合があります。Aurora はこれらのセカンダリリージョンを新しいプライマリリージョンクラスターとまったく同じポイントインタイムデータを持つように再構築します。ストレージボリュームのサイズとリージョン間の距離によっては、再構築タスクが完了するまでに数分から数時間かかることがあります。セカンダリージョンのクラスターが新しいプライマリリージョンからの再構築を完了すると、読み取りアクセスが可能になります。

新しいプライマリライターが昇格して使用可能になると、新しいプライマリリージョンのクラスターは Aurora グローバルデータベースの読み取りおよび書き込み操作を処理できるようになります。アプリケーションのエンドポイントを変更して、新しいエンドポイントを使用してください。Aurora Global Database の作成時に指定された名前を受け入れた場合は、アプリケーションの昇格されたクラスターのエンドポイント文字列から -ro を削除することで、エンドポイントを変更できます。

例えば、セカンダリクラスターのエンドポイント my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com は、そのクラスターがプライマリに昇格したときに my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com になります。

RDS Proxy を使用する場合、アプリケーションの書き込みオペレーションを、新しいプライマリクラスターに関連付けられているプロキシの適切な読み取り/書き込みエンドポイントにリダイレクトします。このプロキシエンドポイントは、デフォルトのエンドポイントでも、カスタムの読み取り/書き込みエンドポイントでもかまいません。詳細については、「RDS Proxy エンドポイントとグローバルデータベースの連携について」を参照してください。

グローバルデータベースクラスターの元のトポロジを復元するために、Aurora は古いプライマリリージョンの可用性を監視します。そのリージョンが正常になり、再び使用可能になるとすぐに、Aurora はそのリージョンをセカンダリリージョンとしてグローバルクラスターに自動的に追加します。古いプライマリリージョンに新しいストレージボリュームを作成する前に、Aurora は障害発生時点で古いストレージボリュームのスナップショットを作成しようとします。これにより、欠落しているデータを回復することができます。この操作が成功すると、Aurora は「rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp」というこのスナップショットを AWS Management Console のスナップショットセクションに入れます。このスナップショットは、DescribeDBClusterSnapshots API オペレーションによって返される情報にも一覧表示されています。

元のトポロジが復元されたら、ビジネスとワークロードにとって最も都合のよいときにスイッチオーバー操作を実行することで、グローバルデータベースを元のプライマリリージョンにフェイルバックできます。これを行うには、「Amazon Aurora Global Database に対するスイッチオーバーの実行」の手順を実行します。

Aurora Global Database をフェイルオーバーするには AWS Management Console、AWS CLI、または RDS API を使用します。

Aurora グローバルデータベースでマネージドフェイルオーバーを実行するには

1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

2. [Databases (データベース)] を選択し、フェイルオーバーしたい Aurora Global Database を見つけます。

3. [アクション] メニューから [グローバルデータベースのスイッチオーバーまたはフェイルオーバー] を選択します。

   

4. [フェイルオーバー (データ損失を許可)] を選択します。

   

5. 新しいプライマリクラスタ の場合、セカンダリ AWS リージョン の 1 つで新しいプライマリクラスターになるアクティブなクラスターを選択してください。

6. confirm を入力して [確認] を選択します。

フェイルオーバーが完了すると、次の画像に示すように、[データベース] リストから Aurora DB クラスターとその現在の状態を確認できます。

Aurora グローバルデータベースでマネージドフェイルオーバーを実行するには

failover-global-cluster CLI コマンドを使用して、Aurora Global Database をフェイルオーバーします。コマンドを使用して、次のパラメータ値を渡します。

• --region — Aurora グローバルデータベースの新しいプライマリにしたいセカンダリ DB クラスターが DB クラスターで実行されている AWS リージョン を指定します。

• --global-cluster-identifier - Aurora Global Database の名前を指定します。

• --target-db-cluster-identifier - Aurora Global Database の新しいプライマリに昇格する Aurora DB クラスターの Amazon リソースネーム (ARN) を指定します。

• --allow-data-loss — これをスイッチオーバー操作ではなくフェイルオーバー操作に明示的に設定します。非同期レプリケーションコンポーネントがレプリケートされたすべてのデータをセカンダリリージョンに送信していない場合、フェイルオーバー操作によってデータの一部が失われる可能性があります。

Linux、macOS、Unix の場合:

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Windows の場合:

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

Aurora Global Database をフェイルオーバーするには、FailoverGlobalCluster API オペレーションを実行します。

Aurora Global Database のマニュアルフェイルオーバーを実行する

シナリオによっては、マネージドフェイルオーバープロセスを使用できない場合があります。一例として、プライマリ DB クラスターとセカンダリ DB クラスターで互換性のあるエンジンバージョンが稼働していない場合が挙げられます。この場合、このマニュアルプロセスに従って、グローバルデータベースをターゲットセカンダリリージョンにフェイルオーバーできます。

これらの変更を行う前、最中、および後に、アプリケーションの書き込みが正しい Aurora クラスターに送信されていることを確認してください。これにより、Aurora Global Database 内の DB クラスター間のデータの不整合 (スプリットブレイン問題) が回避されます。

AWS リージョン の停止に対して再設定を実行した場合、停止状態が解消された後に、AWS リージョン をプライマリに戻すことができます。このためには、古い AWS リージョン を新しいグローバルデータベースに追加し、スイッチオーバープロセスを使用してそのロールを切り替えます。Aurora Global Database では、スイッチオーバーをサポートする Aurora PostgreSQL または Aurora MySQL のバージョンを使用する必要があります。詳細については、「Amazon Aurora Global Database に対するスイッチオーバーの実行」を参照してください。

Amazon Aurora Global Database に対するスイッチオーバーの実行

スイッチオーバーを使用すると、プライマリクラスターのリージョンを定期的に変更できます。この機能は、運用メンテナンス、その他の計画された運用手順など、管理されたシナリオを対象としています。

スイッチオーバーを使用する一般的なユースケースは 3 つあります。

スイッチオーバー中、グローバルデータベースの既存のレプリケーショントポロジを維持しながら、Aurora がプライマリクラスターを選択したセカンダリリージョンにスイッチオーバーします。スイッチオーバープロセスを開始する前に、Aurora はすべてのセカンダリリージョンクラスターがプライマリリージョンクラスターと完全に同期されるまで待ちます。次に、プライマリリージョンの DB クラスターは読み取り専用になり、選択したセカンダリ DB クラスターは、読み取り専用ノードの 1 つを、フルライターステータスに昇格させます。このノードをライターに昇格させると、そのセカンダリクラスターがプライマリクラスターの役割を引き受けることができます。プロセスのスタート時にすべてのセカンダリクラスターがプライマリと同期されているため、新しいプライマリは、データを失うことなく、Aurora Global Database の操作を続行します。プライマリクラスターと選択したセカンダリクラスターが新しいロールを引き受ける間、短時間データベースが使用できなくなります。

アプリケーションの可用性を最適化するには、この機能を使用する前に、次の操作を行うことをお勧めします。

スイッチオーバー中、選択したセカンダリ DB クラスターは、プライマリとして新しいロールに昇格されます。ただし、プライマリ DB クラスターのさまざまな設定オプションは継承されません。構成の不一致は、パフォーマンスの問題、ワークロードの非互換性、およびその他の異常な動作につながる可能性があります。このような問題を回避するには、Aurora Global Database クラスター間の次の違いを解決することをお勧めします。

スイッチオーバープロセスが完了すると、昇格された Aurora DB クラスターは Aurora Global Database の書き込み操作を処理できます。アプリケーションのエンドポイントを変更して、新しいエンドポイントを使用してください。Aurora Global Database の作成時に指定された名前を受け入れた場合は、アプリケーションの昇格されたクラスターのエンドポイント文字列から -ro を削除することで、エンドポイントを変更できます。

例えば、セカンダリクラスターのエンドポイント my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com は、そのクラスターがプライマリに昇格したときに my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com になります。

RDS Proxy を使用する場合、アプリケーションの書き込みオペレーションを、新しいプライマリクラスターに関連付けられているプロキシの適切な読み取り/書き込みエンドポイントにリダイレクトします。このプロキシエンドポイントは、デフォルトのエンドポイントでも、カスタムの読み取り/書き込みエンドポイントでもかまいません。詳細については、「RDS Proxy エンドポイントとグローバルデータベースの連携について」を参照してください。

Aurora Global Database をスイッチオーバーするには、AWS Management Console、AWS CLI、または RDS API を使用します。

Aurora グローバルデータベースでスイッチオーバーを実行するには

1. AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。

2. [データベース] を選択し、フェイルオーバーしたい Aurora Global Database を見つけます。

3. [アクション] メニューから [グローバルデータベースのスイッチオーバーまたはフェイルオーバー] を選択します。

   

4. [スイッチオーバー] を選択します。

   

5. 新しいプライマリクラスタ の場合、セカンダリ AWS リージョン の 1 つで新しいプライマリクラスターになるアクティブなクラスターを選択してください。

6. [確認] を選択します。

スイッチオーバーが完了すると、次の画像に示すように、[データベース] リストから Aurora DB クラスターとその現在のロールを確認できます。

Aurora グローバルデータベースでスイッチオーバーを実行するには

switchover-global-cluster CLI コマンドを使用して、Aurora Global Database をスイッチオーバーします。コマンドを使用して、次のパラメータ値を渡します。

• --region – Aurora Global Database のプライマリ DB クラスターが実行されている AWS リージョン を指定します。

• --global-cluster-identifier - Aurora Global Database の名前を指定します。

• --target-db-cluster-identifier - Aurora Global Database のプライマリに昇格する Aurora DB クラスターの Amazon リソースネーム (ARN) を指定します。

Linux、macOS、Unix の場合:

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Windows の場合:

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

Aurora グローバルデータベースをスイッチオーバーするには、SwitchoverGlobalCluster API オペレーションを実行します。

Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理

Aurora PostgreSQL - ベースのグローバルデータベースでは、rds.global_db_rpo パラメータを使用して、目標復旧ポイント (RPO) を管理できます。RPO (目標復旧時点) は、停止時に失われる可能性があるデータの最大量を表します。

Aurora PostgreSQL - ベースのグローバルデータベースに RPO を設定する場合、Aurora はすべてのセカンダリクラスターの RPO ラグタイムをモニタリングし、少なくとも 1 つのセカンダリクラスターがターゲット RPO ウィンドウ内に留まることを確認します。RPO ラグタイムは、もう 1 つの時間ベースのメトリクスです。

RPO は、データベースが、フェイルオーバー後に新しい AWS リージョン でオペレーションを再開するときに使用されます。Aurora は、RPO と RPO ラグタイムを評価して、以下に示すように、プライマリでのトランザクションをコミット (またはブロック) します。

つまり、すべてのセカンダリクラスターがターゲット RPO より遅れている場合、Aurora は、セカンダリクラスターの少なくとも 1 つが追いつくまでプライマリクラスターのトランザクションを一時停止します。1 つ以上のセカンダリ DB クラスターのラグタイムが RPO を下回るとすぐに、一時停止中のトランザクションが再開され、コミットされます。その結果、RPO (目標復旧時点) に達するまで、トランザクションはコミットできません。

rds.global_db_rpo パラメータは動的です。遅延が十分に減少するまですべての書き込みトランザクションを停止させたくない場合は、すぐにリセットできます。この場合、Aurora は少し遅れて変更を認識して実装します。

このパラメータを以下に示すように設定すると、生成されたメトリクスをモニタリングすることもできます。これを行うには、psql または別のツールを使用して、Aurora Global Database のプライマリ DB クラスターをクエリし、Aurora PostgreSQL - ベースのグローバルデータベースの操作に関する詳細情報を取得できます。この方法については、「Aurora PostgreSQL ベースのグローバルデータベースのモニタリング」を参照してください。

目標復旧時点の設定

rds.global_db_rpo パラメータは、PostgreSQL データベースの RPO 設定を制御します。このパラメータは、Aurora PostgreSQL でサポートされています。有効な値の rds.global_db_rpo 範囲は 20 秒から 2,147,483,647 秒 (68 年) です。ビジネスニーズとユースケースに合わせて、現実的な価値をお選びください。例えば、RPO (目標復旧時点) に最大 10 分かかる場合があります。この場合、値を 600 に設定します。

この値は、AWS Management Console、AWS CLI、または RDS API を使用して、Aurora PostgreSQL ベースのグローバルデータベースに設定します。

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

目標復旧時点の表示

グローバルデータベースの目標復旧時点 (RPO) は、各 DB クラスターの rds.global_db_rpo パラメータに保存されます。表示するセカンダリクラスターのエンドポイントに接続し、この値についてインスタンスのクエリに psql を使用できます。

db-name=>show rds.global_db_rpo;

このパラメータが設定されていない場合、クエリは次の値を返します。

rds.global_db_rpo
-------------------
 -1
(1 row)

この次の応答は、1 分の RPO 設定を持つセカンダリ DB クラスターからのものです。

rds.global_db_rpo
-------------------
 60
(1 row)

CLI を使用して、クラスターのすべての rds.global_db_rpo パラメータ値を取得することで、Aurora DB クラスターのいずれかで user がアクティブかどうかを調べるための値を取得することもできます。

Linux、macOS、Unix の場合:

aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Windows の場合:

aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

このコマンドは、user または default-engine DB クラスターパラメータではないすべての system パラメータについて、次のような出力を返します。

{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

クラスターパラメータグループのパラメータ表示の詳細については、Amazon Aurora の DB クラスターパラメータグループのパラメータ値の表示 を参照してください。

目標復旧時点の無効化

RPO を無効にするには、rds.global_db_rpo パラメータをリセットします。AWS Management Console、AWS CLI、または RDS API を使用してパラメータをリセットできます。

aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"