Amazon Aurora グローバルデータベースの使用 - Amazon Aurora

Amazon Aurora グローバルデータベースの使用

次に、Aurora グローバルデータベースを作成するために使用される Amazon Aurora グローバルデータベース機能の説明を示します。Aurora グローバルデータベースはそれぞれ、複数の AWS リージョンにまたがっているため、低レイテンシーのグローバル読み取りと AWS リージョン全体の停止からの災害対策が可能になります。

Aurora グローバルデータベースの概要

Aurora グローバルデータベースは、1 つのプライマリ AWS リージョン (データをマスターとして管理) と最大 5 つのセカンダリ AWS リージョン (読み取り専用) で構成されます。Aurora は、通常 1 秒未満のレイテンシーでセカンダリ AWS リージョンにデータをレプリケートします。書き込みオペレーションは、プライマリ AWS リージョン内のプライマリ DB インスタンスに直接発行します。

Aurora グローバルデータベースでは、専用のインフラストラクチャを使用してデータをレプリケートします。そのため、データベースのリソースを完全に利用しながら、アプリケーションワークロードを処理します。複数のリージョンをまたいで使用されるアプリケーションは、セカンダリ AWS リージョンのリーダーインスタンスを使用して低レイテンシーの読み取りを行うことができます。場合によっては、データベースが劣化したり、AWS リージョンで分離されたりすることがあります。このような場合は、グローバルデータベースを使用し、セカンダリの AWS リージョンのいずれかをプロモートして、1 分以内に完全な読み取り/書き込みワークロードを実行できます。

データをマスターとして管理するプライマリ AWS リージョンの Aurora クラスターは、読み取りと書き込みの両方のオペレーションを実行します。セカンダリリージョンのクラスターは低レイテンシーの読み取りを可能にします。セカンダリクラスターは、1 つ以上の DB インスタンス(Aurora レプリカ)を追加することで別個にスケールアップできます。災害対策の場合は、セカンダリクラスターを Aurora グローバルデータベースから解除して昇格させることで、読み取り/書き込みオペレーション全体に対応できます。

書き込みオペレーションはプライマリクラスターのみが実行します。書き込みオペレーションを実行するクライアントは、プライマリクラスターの DB クラスターエンドポイントに接続します。

Aurora グローバルデータベースの利点

Aurora グローバルデータベースでは、次の利点があります。

  • セカンダリクラスターは、単一の Aurora クラスターのキャパシティーをはるかに超える読み取りのスケーリングを提供します。

    セカンダリクラスターには、書き込みのプライマリ DB インスタンスがありません。この機能により、1 つの Aurora クラスターで最大 15 個の制限ではなく、最大 16 個の読み取り専用の Aurora レプリカインスタンスを持つことができます。

  • Aurora グローバルデータベースによるレプリケーションは、プライマリ DB クラスターのパフォーマンスに対する影響がほとんどありません。DB インスタンスのリソースは、全面的にアプリケーションの読み取りおよび書き込みワークロードに当てられます。

  • 変更は、最小限の遅延時間 (通常は 1 秒未満) で AWS リージョン間でレプリケートされます。

  • セカンダリクラスターは、災害対策の高速なフェイルオーバーを可能にします。通常、1 分未満でセカンダリクラスターを昇格させて書き込みに対応できます。

  • リモートの AWS リージョンのアプリケーションは、セカンダリクラスターから読み取ると、クエリのレイテンシーが低くなります。

Aurora グローバルデータベースの制限

現在、Aurora グローバルデータベースには以下の制限があります。

  • Aurora グローバルデータベースは、次の Aurora バージョンで使用できます。

    • Aurora MySQL。MySQL 5.6 と互換性がある Aurora MySQL では、バージョン 5.6.10a またはバージョン 1.22 以降を使用できます。MySQL 5.7 と互換性がある Aurora MySQL では、バージョン 2.07 以降を使用できます。

    • Aurora PostgreSQL バージョン 10.11、10.12、11.7 以降の PostgreSQL との互換性を備えています。

  • Aurora グローバルデータベースには、 db.r4 または db.r5 インスタンスクラスのどちらを使用するかを選択できます。db.t2 または db.t3 インスタンスクラスは使用できません。

  • Aurora グローバルデータベースは、次の AWS リージョンで使用できます。

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

    • 米国東部 (オハイオ)

    • 米国西部 (北カリフォルニア)

    • 米国西部 (オレゴン)

    • 欧州 (アイルランド)

    • 欧州 (ロンドン)

    • 欧州 (パリ)

    • 欧州 (フランクフルト)

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

    • アジアパシフィック (シンガポール)

    • アジアパシフィック (シドニー)

    • アジアパシフィック (東京)

    • アジアパシフィック (ソウル)

    • カナダ (中部)

  • セカンダリクラスターは、プライマリクラスターとは異なる AWS リージョンに存在する必要があります。

  • グローバルデータベースクラスターをアップグレードするには、プライマリクラスターより先にセカンダリクラスターをアップグレードする必要があります。アップグレードの詳細については、「Amazon Aurora MySQL のデータベースアップグレードおよびパッチ」または「Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード」を参照してください。

  • データベースアクティビティストリームは、プライマリクラスターでのみ開始でき、セカンダリクラスターでは開始できません。データベースアクティビティストリームについては、「Amazon Aurora でデータベースアクティビティストリームを使用する」を参照してください。

Aurora グローバルデータベースでは以下の機能はサポートされていません。

Aurora グローバルデータベースの作成

Aurora グローバルデータベースは複数の AWS リージョンにまたがります。まず、グローバルデータベース自体と読み取り/書き込みプライマリクラスターを同じ場所に作成します。次に、別の AWS リージョンに 1 つ以上の読み取り専用セカンダリクラスターを追加します。

プライマリクラスターとセカンダリクラスターの名前を指定する場合は、既存の Aurora クラスター(他の AWS リージョンにある場合でも)とは異なる名前を選択します。

重要

Aurora グローバルデータベースを作成する前に、Amazon Relational Database Service ユーザーガイドの「Amazon RDS のセットアップ」に従ってアカウント、ネットワーク、およびセキュリティ設定のセットアップタスクを完了してください。

コンソールを使用して Aurora MySQL バージョン 5.6.10a のグローバルデータベースを作成するには、2 番目のプロセスを参照してください。

AWS マネジメントコンソール を使用して Aurora グローバルデータベースを作成するには

  1. 既存の Aurora クラスターから開始するか、新しいクラスターを作成します。Aurora MySQL バージョン 1.22.0 以上、Aurora MySQL バージョン 2.07 以上、または Aurora PostgreSQL バージョン 10.11 を使用します。クラスターの作成については、「DB クラスターを作成して Aurora MySQL DB クラスターのデータベースに接続する」または「DB クラスターを作成して Aurora PostgreSQL DB クラスターのデータベースに接続する」を参照してください。

  2. Aurora クラスターが作成され、使用可能になったら、1 つまたは複数のセカンダリクラスターを作成します。これを行うには、「Aurora グローバルデータベースへの AWS リージョンの追加」の手順に従います。各セカンダリクラスターは、元のクラスターとは異なる AWS リージョンにあります。

Aurora MySQL バージョン 5.6.10a では、クラスター作成時にクラスターに Aurora グローバルデータベースとの互換性を持たせることを選択する必要があります。この Aurora MySQL バージョンでクラスターを作成する場合は、 [グローバル] の選択肢のみが AWS マネジメントコンソール に表示されます。Aurora MySQL バージョン 1.22 以降では、クラスターの作成時に特別な選択を行わずに、Aurora グローバルデータベースを含む任意のクラスターを使用できます。

5.6.10a と 1.22 の間の Aurora MySQL バージョンでは、クラスターの作成時に特別な選択は行いません。ただし、このようなクラスターを Aurora グローバルデータベースで使用するには、まず Aurora MySQL バージョン 1.22 以降にアップグレードする必要があります。

AWS マネジメントコンソール を使用して Aurora MySQL グローバルデータベースを作成するには (バージョン 5.6.10a のみ)

  1. AWS マネジメントコンソール にサインインし、Aurora グローバルデータベースが使用できる AWS リージョンで Amazon RDS コンソールを開きます。詳細については、「Aurora グローバルデータベースの制限」を参照してください。

  2. [データベースの作成] を選択します。

  3. [エンジンの選択] ページで Aurora エンジンを選択し、[データベースロケーション] で [グローバル] を選択します。例については、以下のイメージを参照してください。

    注記

    [Standard Create (標準作成)] が選択されていることを確認してください。Aurora グローバルデータベースに必要なオプションは、[Standard create (標準作成)] で表示されます。[Easy Create (簡易作成)] を選択しないでください。

    1. エンジンとして Amazon Aurora を選択します。

      
                    データベースを作成するときのエンジンオプションのスクリーンショット。
    2. [MySQL と互換性がある Amazon Aurora] エディションを選択します。

    3. [バージョン] に 5.6.10a を選択します。

    4. データベースの場所として [グローバル] を選択します。

      
                    Aurora クラスターの作成時にデータベースの場所を選択するオプションのスクリーンショット。Aurora グローバルデータベースを作成するには [グローバル] を選択する。
      注記

      [Global (グローバル)] を選択すると、グローバルデータベースとプライマリ Aurora クラスターが作成されます。グローバルデータベースが作成されて使用可能になると、セカンダリ AWS リージョンを追加できます。

  4. 他の Aurora クラスターの場合と同じ決定プロセスを使用して残りの設定を完了します。Aurora DB クラスター作成の詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。

    
                Aurora グローバルデータベース作成時のその他の設定を示すスクリーンショット。
  5. [Create] を選択します。

プライマリ DB クラスターが作成されて使用可能になったら、「Aurora グローバルデータベースへの AWS リージョンの追加」の手順に従って 1 つ以上のセカンダリクラスターを作成します。

CLI を使用して Aurora グローバルデータベースを作成するには、次のいずれかの手順を使用します。

  • Aurora グローバルデータベースを作成し、次にプライマリ AWS リージョンを追加して、この AWS リージョンに DB インスタンスを追加します。

  • または、最初にプライマリクラスターを作成し、次にグローバルデータベースを作成して、どのクラスターをプライマリクラスターとして使用するかを指定することもできます。

Aurora グローバルデータベースを作成し、次にプライマリ AWS リージョンと DB インスタンスを追加するには

  1. Aurora グローバルデータベースを作成し、次にプライマリ AWS リージョンクラスターを追加します。

    1. Aurora グローバルデータベース自体を作成します。当初は、関連付けられているクラスターがありません。以下の値を使用します。

      • Aurora MySQL の場合、--engine パラメータに aurora を指定します。

      • Aurora PostgreSQL の場合、--engine パラメータには aurora-postgresql--engine-version パラメータには 10.11 をそれぞれ指定します。

      Linux、macOS、Unix の場合:

      aws rds create-global-cluster --region primary_region \ --global-cluster-identifier global_database_id \ --engine engine_type \ --engine-version version # optional

      Windows の場合:

      aws rds create-global-cluster ^ --global-cluster-identifier global_database_id ^ --engine engine_type ^ --engine-version version # optional

      その他のオプションの詳細については、「create-global-cluster」を参照してください。

    2. 次の例に示すように、AWS CLI の describe-global-clusters コマンドを使用して、Aurora グローバルデータベースが使用可能になったことを確認します。

      aws rds describe-global-clusters --region primary_region --global-cluster-identifier global_database_id # ID is optional

      結果に available のステータスが表示されたら、次のステップに進みます。

    3. Aurora グローバルデータベースのプライマリクラスターを作成します。これを行うには、AWS CLI の create-db-cluster コマンドを使用します。グローバルデータベースを作成したときと同じ --global-cluster-identifier 値を指定します。

      • Aurora MySQL の場合、--engine パラメータに aurora を指定します。

      • Aurora PostgreSQL の場合、--engine パラメータには aurora-postgresql--engine-version パラメータには 10.11 をそれぞれ指定します。

      Linux、macOS、Unix の場合:

      aws rds create-db-cluster \ --region primary_region \ --db-cluster-identifier db_cluster_id \ --master-username master_userid \ --master-user-password master_password \ --engine { aurora | aurora-mysql | aurora-postgresql } \ --engine-version version \ --global-cluster-identifier global_database_id

      Windows の場合:

      aws rds create-db-cluster ^ --region primary_region ^ --db-cluster-identifier db_cluster_id ^ --master-username master_userid ^ --master-user-password master_password ^ --engine { aurora | aurora-mysql | aurora-postgresql } ^ --engine-version version ^ --global-cluster-identifier global_database_id
      注記

      Aurora MySQL バージョン 5.6.10a の場合は、--engine-mode パラメータに global も指定する必要があります。

      その他のオプションの詳細については、「create-db-cluster」を参照してください。

    4. Aurora クラスターが使用可能になったことを確認します。次の例に示すように、AWS CLI の describe-db-clusters コマンドを使用して確認します。

      aws rds describe-db-clusters --region primary_region --db-cluster-identifier db_cluster_id # ID is optional

      結果に available のステータスが表示されたら、次のステップに進みます。

  2. プライマリクラスターのプライマリ DB インスタンスを作成します。これを行うには、AWS CLI の create-db-instance コマンドを使用します。

    • --engine パラメータを次のように指定します。

      • Aurora MySQL バージョン 1 または 5.6.10a の場合は、--engine aurora を使用します。

      • Aurora MySQL バージョン 2 の場合は、--engine aurora-mysql を使用します。

      • Aurora PostgreSQL の場合は、--engine aurora-postgresql を使用します。

    • 必要に応じて、--engine-version パラメータを指定して、使用する特定のバージョンを選択します。

    • Aurora MySQL バージョン 5.6.10a の場合は、--engine-mode global を指定します。

    以下の例のように指定します。

    Linux、macOS、Unix の場合:

    aws rds create-db-instance \ --db-cluster-identifier db_cluster_id \ --db-instance-class instance_class \ --db-instance-identifier db_instance_id \ --engine { aurora | aurora-mysql | aurora-postgresql} \ --engine-version version \ --region primary_region

    Windows の場合:

    aws rds create-db-instance ^ --db-cluster-identifier db_cluster_id ^ --db-instance-class instance_class ^ --db-instance-identifier db_instance_id ^ --engine { aurora | aurora-mysql | aurora-postgresql } ^ --engine-version version ^ --region primary_region

    --master-username パラメータと --master-user-password パラメータを含める必要はありません。これらのパラメータ値は、プライマリ DB クラスターから取得されます。

    その他のオプションの詳細については、「create-db-instance」を参照してください。

  3. Aurora グローバルデータベースのプライマリクラスターが使用可能になったことを確認します。次の例に示すように、AWS CLI の describe-db-clusters コマンドを使用して確認します。

    aws rds describe-db-clusters --db-cluster-identifier sample-global-cluster
  4. describe-db-clusters の結果にステータスが available と表示されたら、レプリケーションを開始できるようにプライマリクラスターのプライマリインスタンスを作成します。そのためには、以下の例に示すように AWS CLI の create-db-instance コマンドを使用します。

    Linux、macOS、Unix の場合:

    aws rds create-db-instance \ --db-cluster-identifier sample-global-cluster \ --db-instance-class instance_class \ --db-instance-identifier sample-replica-instance \ --engine aurora

    Windows の場合:

    aws rds create-db-instance ^ --db-cluster-identifier sample-global-cluster ^ --db-instance-class instance_class ^ --db-instance-identifier sample-replica-instance ^ --engine aurora

    DB インスタンスが作成されて使用可能になると、レプリケーションが始まります。DB インスタンスが使用可能かどうかを確認するには、AWS CLI の describe-db-instances コマンドを呼び出します。

別の手順として、最初にプライマリ DB クラスターを作成し、後でグローバルデータベースを作成することもできます。

  1. 空の Aurora DB クラスターを作成します。

    • Aurora MySQL バージョン 5.6.10a の場合は、以下のパラメータと値を指定します。

      • --engine aurora

      • --engine-version 5.6.10a

      • --engine-mode global

        この設定は、aurora --engine 設定と必ず組み合わせて使用してください。

    • Aurora PostgreSQL の場合は、次のパラメータと値を指定します。

      • --engine aurora-postgresql

      • --engine-version 10.11

    Linux、macOS、Unix の場合:

    aws rds --region primary_region \ create-db-cluster \ --db-cluster-identifier primary_cluster_id \ --master-username master_userid \ --master-user-password master_password \ --engine { aurora | aurora-mysql | aurora-postgresql } \ --engine-version version aws rds --region primary_region \ create-db-instance \ --db-instance-class instance_class \ --db-cluster-identifier primary_cluster_id \ --db-instance-identifier db_instance_id \ --engine { aurora | aurora-mysql | aurora-postgresql }

    Windows の場合:

    aws rds --region primary_region ^ create-db-cluster ^ --db-cluster-identifier primary_cluster_id ^ --master-username master_userid ^ --master-user-password master_password ^ --engine { aurora | aurora-mysql | aurora-postgresql } ^ --engine-version version aws rds --region primary_region ^ create-db-instance ^ --db-instance-class instance_class ^ --db-cluster-identifier primary_cluster_id ^ --db-instance-identifier db_instance_id ^ --engine { aurora | aurora-mysql | aurora-postgresql }
  2. 次の値を使用して Aurora DB クラスター内に DB インスタンスを作成します。

    • Aurora MySQL バージョン 5.6.10a の場合は、--engine aurora--engine-mode global を指定します。

    • Aurora PostgreSQL の場合は、--engine aurora-postgresql を指定します。

    次に Aurora PostgreSQL の例を示します。

    Linux、macOS、Unix の場合:

    aws rds --region primary_region \ create-db-instance \ --db-instance-class instance_class \ --db-cluster-identifier primary_cluster_id \ --db-instance-identifier db_instance_id \ --engine aurora-postgresql

    Windows の場合:

    aws rds --region primary_region ^ create-db-instance ^ --db-instance-class instance_class ^ --db-cluster-identifier primary_cluster_id ^ --db-instance-identifier db_instance_id ^ --engine aurora-postgresql
  3. プライマリ DB クラスターと DB インスタンスが作成されて使用可能になったら、Aurora グローバルデータベースを作成します。これを行うには、Aurora グローバルデータベースを作成する AWS リージョンで AWS CLI create-global-cluster コマンドを呼び出します。--source-db-cluster-identifier パラメータを使用して、以前に作成したプライマリ DB クラスターを指定します。

    Linux、macOS、Unix の場合:

    aws rds create-global-cluster \ --global-cluster-identifier global_database_id \ --source-db-cluster-identifier primary_cluster_ARN

    Windows の場合:

    aws rds create-global-cluster ^ --global-cluster-identifier global_database_id ^ --source-db-cluster-identifier primary_cluster_ARN

RDS API を使用して Aurora グローバルデータベースを作成するには、CreateGlobalCluster オペレーションを実行します。

Aurora グローバルデータベースへの AWS リージョンの追加

Aurora グローバルデータベースとそのプライマリクラスターを作成したら、1 つ以上の新しい AWS リージョンを追加してグローバルフットプリントを拡大します。このプロセスでは、1 つ以上のセカンダリ Aurora クラスターをアタッチします。各セカンダリクラスターは、プライマリクラスターおよび他のセカンダリクラスターとは異なる AWS リージョンに存在する必要があります。

注記

Aurora グローバルデータベースにアタッチできるセカンダリ Aurora クラスターの最大数は 5 です。したがって、グローバルデータベースに関連付けることができるクラスターの最大数は 6 です。1 つは読み取り/書き込みインスタンスとオプションのリーダーインスタンスを持つプライマリクラスターで、5 つは読み取り専用のセカンダリクラスターです。

グローバルデータベース内のセカンダリクラスターごとに、プライマリクラスター内のリーダー DB インスタンスの最大数が 1 つ減少します。たとえば、グローバルデータベースに 3 つのセカンダリクラスターがある場合、プライマリクラスターのリーダー DB インスタンスの最大数は 15 ではなく 12 になります。場合によっては、プライマリクラスターのリーダーインスタンスの数に、セカンダリクラスターの数を加えた合計が 15 個になることがあります。そうであれば、グローバルデータベースにセカンダリクラスターを追加することはできません。

AWS マネジメントコンソール を使用して Aurora グローバルデータベースに AWS リージョンを追加するには

  1. AWS マネジメントコンソール のナビゲーションペインで、[データベース] を選択します。

  2. セカンダリクラスターを作成する Aurora グローバルデータベースのチェックボックスを選択します。プライマリクラスターまたはそれに含まれている DB インスタンスがまだ Creating の状態である場合は、すべてが Available の状態になるまで待ちます。

  3. [アクション] で、[リージョンの追加] を選択します。

    
                Aurora グローバルデータベースの [リージョンの追加] オプションを示すスクリーンショット。
  4. [リージョンの追加] ページで、セカンダリ AWS リージョンを選択します。

    
                Aurora グローバルデータベースの [リージョンの追加] ダイアログを示すスクリーンショット。
  5. 新しい AWS リージョンで Aurora クラスターの残りのフィールドを設定し、[リージョンの追加] を選択します。

AWS CLI を使用して Aurora グローバルデータベースに AWS リージョンを追加するには、create-db-cluster コマンドを実行します。

以下のコマンドでは、新しい Aurora クラスターを作成し、これを読み取り専用のセカンダリクラスターとしてグローバルデータベースにアタッチします。次に、この新しいクラスターに DB インスタンスを追加します。create-db-cluster コマンドの --global-cluster-identifier オプションで、新しいクラスターをアタッチする先のグローバルデータベースを指定します。--engine パラメータを次のように指定します。

  • Aurora MySQL バージョン 1 または 5.6.10 の場合は、--engine aurora を使用

  • Aurora MySQL バージョン 2 の場合は、--engine aurora-mysql を使用

  • Aurora PostgreSQL の場合は、--engine aurora-postgresql を使用

暗号化されたクラスターの場合は、--source-region オプションでプライマリ AWS リージョンと一致する値を指定します。

次に Aurora PostgreSQL の例を示します。

Linux、macOS、Unix の場合:

aws rds --region secondary_region \ create-db-cluster \ --db-cluster-identifier secondary_cluster_id \ --global-cluster-identifier global_database_id \ --engine { aurora | aurora-mysql | aurora-postgresql } --engine-version version aws rds --region secondary_region \ create-db-instance \ --db-instance-class instance_class \ --db-cluster-identifier secondary_cluster_id \ --db-instance-identifier db_instance_id \ --engine { aurora | aurora-mysql | aurora-postgresql }

Windows の場合:

aws rds --region secondary_region ^ create-db-cluster ^ --db-cluster-identifier secondary_cluster_id ^ --global-cluster-identifier global_database_id_id ^ --engine { aurora | aurora-mysql | aurora-postgresql } ^ --engine-version version aws rds --region secondary_region ^ create-db-instance ^ --db-instance-class instance_class ^ --db-cluster-identifier secondary_cluster_id ^ --db-instance-identifier db_instance_id ^ --engine { aurora | aurora-mysql | aurora-postgresql }

RDS API を使用して Aurora グローバルデータベースに新しい AWS リージョンを追加するには、CreateDBCluster オペレーションを実行します。GlobalClusterIdentifier パラメータを使用して、既存のグローバルデータベースの識別子を指定します。

Aurora グローバルデータベースからのクラスターの削除

Aurora グローバルデータベースから Aurora クラスターを削除すると、クラスターはリージョンレベルのクラスターに戻ります。読み取り/書き込み機能は完全に保持されますが、プライマリクラスターとは同期されなくなります。

プライマリクラスターの性能低下や切断が発生した場合は、グローバルデータベースから Aurora クラスターを解除できます。Aurora グローバルデータベースのフェイルオーバーを実行するには、元のグローバルデータベースからセカンダリクラスターの 1 つを削除する必要があります。次に、そのクラスターを新しい Aurora グローバルデータベースのプライマリクラスターとして使用します。詳細については、「Aurora グローバルデータベースのフェイルオーバー」を参照してください。

グローバルデータベースが不要になった場合は、グローバルデータベース自体を削除する前に、すべてのセカンダリクラスターを解除し、さらにプライマリクラスターを解除する必要があります。次に、解除したクラスターの一部またはすべてを削除するか、一部またはすべてを引き続き単一リージョンの Aurora クラスターとして使用できます。詳細については、「Aurora グローバルデータベースの削除」を参照してください。

AWS マネジメントコンソール で Aurora グローバルデータベースから Aurora クラスターを解除するには

  1. [データベース] ページでクラスターを選択します。

  2. [アクション] で [グローバルから削除] を選択します。解除したクラスターは、読み取り/書き込み機能を完全に備えた、通常の Aurora クラスターになります。プライマリクラスターとは同期されなくなります。

    
            Aurora グローバルデータベースからのセカンダリクラスターの解除を確認するプロンプトを示すスクリーンショット。

    グローバルデータベースにセカンダリクラスターがまだ関連付けられている場合は、プライマリクラスターを解除できません。

    すべてのセカンダリクラスターを解除または削除したら、次にプライマリクラスターを同じ方法で解除できます。

Aurora グローバルデータベースから解除したクラスターは、依然として [データベース] ページに表示されますが、[Global (グローバル)]、[Primary (プライマリ)] [Secondary (セカンダリ)] のラベルは付かなくなります。


            Aurora グローバルデータベースから解除された後のクラスターを示すスクリーンショット。

AWS CLI を使用して Aurora グローバルデータベースから Aurora クラスターを解除するには、remove-from-global-cluster コマンドを実行します。

以下のコマンドはセカンダリクラスターを解除し、次に Aurora グローバルデータベースからプライマリクラスターを解除します。解除するクラスターを識別するには、どちらの場合も --db-cluster-identifier パラメータを使用します。Aurora グローバルデータベースを識別するには、--global-cluster-identifier パラメータを使用します。

Linux、macOS、Unix の場合:

aws rds --region secondary_region \ remove-from-global-cluster \ --db-cluster-identifier secondary_cluster_ARN \ --global-cluster-identifier global_database_id ... repeat above command with a different --region for all secondary clusters ... aws rds --region primary_region \ remove-from-global-cluster \ --db-cluster-identifier primary_cluster_ARN \ --global-cluster-identifier global_database_id

Windows の場合:

aws rds --region secondary_region ^ remove-from-global-cluster ^ --db-cluster-identifier secondary_cluster_ARN ^ --global-cluster-identifier global_database_id ... repeat above command with a different --region for all secondary clusters ... aws rds --region primary_region ^ remove-from-global-cluster ^ --db-cluster-identifier primary_cluster_ARN ^ --global-cluster-identifier global_database_id

RDS API を使用して Aurora グローバルデータベースから Aurora クラスターを解除するには、RemoveFromGlobalCluster アクションを実行します。

Aurora グローバルデータベースの削除

Aurora グローバルデータベースを削除する前に、まずグローバルデータベースのクラスターを解除または削除する必要があります。通常、グローバルデータベースにはビジネスクリティカルなデータが含まれているため、グローバルデータベースおよび関連付けられているクラスターを単一のステップで削除することはできません。グローバルデータベースからクラスターを解除する手順については、「Aurora グローバルデータベースからのクラスターの削除」を参照してください。これにより、クラスターが再びスタンドアロンの Aurora クラスターになります。削除後にクラスターを削除する手順については、「Aurora DB クラスターのDB インスタンスを削除する」を参照してください。

AWS マネジメントコンソール で Aurora グローバルデータベースを削除するには、まずグローバルデータベースに関連付けられているすべてのセカンダリクラスターを解除または削除します。次に、プライマリクラスターを削除し、最後にグローバルデータベース自体を削除します。

Aurora クラスターからライターインスタンスを削除すると、クラスター自体が削除されます。通常、グローバルデータベースにはビジネスクリティカルなデータが含まれているため、グローバルデータベースおよび関連付けられているクラスターを単一のステップで削除することはできません。

グローバルデータベースからクラスターを解除する手順については、「Aurora グローバルデータベースからのクラスターの削除」を参照してください。削除後にクラスターを削除する手順については、「Aurora DB クラスターのDB インスタンスを削除する」を参照してください。Aurora クラスターからプライマリインスタンスを削除すると、クラスター自体が削除されます。

AWS マネジメントコンソール を使用して Aurora グローバルデータベースを削除するには

  1. Aurora グローバルデータベースから他のすべてのクラスターが解除されていることを確認します。

    次のスクリーンショットに示すように、グローバルデータベースにネストされたクラスターが含まれている場合は、グローバルデータベースをまだ削除できません。グローバルデータベースに関連付けられているクラスターごとに、「Aurora グローバルデータベースからのクラスターの削除」の手順に従ってください。

    
                前述のグローバルデータベースは、クラスターが関連付けられているため、削除できません。

    グローバルデータベースに関連付けられたクラスターがなくなると、グローバルデータベースを削除できます。次のスクリーンショットは、グローバルデータベースとの関連付けを解除された global-db-demo クラスターを示しています。

    
                グローバルデータベースからすべてのクラスターが解除されたので、グローバルデータベースを削除できる。
  2. [データベース] ページまたはグローバルデータベースの詳細ページで、[アクション] の [削除] を選択します。

AWS CLI を使用して Aurora グローバルデータベースの一部であるクラスターを削除するには、delete-global-cluster コマンドを実行します。

次のコマンドでは、指定したグローバルクラスター ID の Aurora グローバルデータベースを削除します。

Linux、macOS、Unix の場合:

aws rds --region primary_region \ delete-global-cluster \ --global-cluster-identifier global_database_id

Windows の場合:

aws rds --region primary_region ^ delete-global-cluster ^ --global-cluster-identifier global_database_id

RDS API を使用して Aurora グローバルデータベースの一部であるクラスターを削除するには、DeleteGlobalCluster オペレーションを実行します。

Aurora グローバルデータベースへのデータのインポート

データを Aurora グローバルデータベースにインポートするには、以下のいずれかの技術を使用します。

  • Aurora クラスターまたは Amazon RDS DB インスタンスのスナップショットを作成し、これを Aurora グローバルデータベースのプライマリクラスターとして復元します。現時点では、Aurora MySQL バージョン 1、Aurora MySQL バージョン 2、または Aurora PostgreSQL 10.11 と互換性があるソースからのスナップショットであることが必要です。

    次に、Aurora MySQL 5.6 インスタンスを復元する例を示します。

    
            Aurora グローバルデータベースの [スナップショットの復元] ページを示すスクリーンショット。
  • クラスターデータを前の状態に復元するには、プライマリクラスターで特定時点への復元を使用します。詳細については、「特定の時点への DB クラスターの復元」を参照してください。

Aurora グローバルデータベースの場合の決定的な違いは、データのインポート先が常にプライマリクラスターとして指定したクラスターであることです。最初のデータインポートは、インポート先のクラスターを Aurora グローバルデータベースに追加する前または追加した後に行うことができます。プライマリクラスターのすべてのデータは、セカンダリクラスターに自動的にレプリケートされます。

Aurora グローバルデータベースの設定

AWS マネジメントコンソール の [データベース] ページには、すべての Aurora グローバルデータベースが、プライマリクラスターおよびセカンダリクラスターと一緒に表示されます。Aurora グローバルデータベースは、独自の構成設定を持つオブジェクトです。プライマリクラスターとセカンダリクラスターに関連付けられた AWS リージョンなどの設定が含まれています。次に Aurora MySQL の例を示します。


        AWS マネジメントコンソール で選択された Aurora グローバルデータベースおよび関連付けられた構成設定を示すスクリーンショット。

次のスクリーンショットに示すように、Aurora グローバルデータベースを選択し、その設定を変更できます。


        Aurora グローバルデータベースの設定を変更するページを示すスクリーンショット。

Aurora グローバルデータベース内の Aurora クラスターごとに個別にパラメータグループを設定できます。ほとんどのパラメータの動作は、他の種類の Aurora クラスターと同じです。セカンダリクラスターをプライマリクラスターに昇格させる場合は、予期しない動作の変化を避けるために、グローバルデータベース内のすべてのクラスター間で設定を一貫させることをお勧めします。たとえば、別のクラスターがプライマリクラスターを肩代わりしたときに動作が変わらないように、タイムゾーンと文字セットに同じ設定を使用します。

aurora_enable_repl_bin_log_filteringaurora_enable_replica_log_compression の構成設定は何の効果もありません。

Aurora グローバルデータベースへの接続

読み取り専用クエリトラフィックの場合、AWS リージョンの Aurora クラスターの読み取りエンドポイントに接続します。

データ操作言語 (DML) またはデータ定義言語 (DDL) のステートメントを実行するには、プライマリクラスターのクラスターエンドポイントに接続します。このエンドポイントは、アプリケーションとは異なる AWS リージョンに存在する場合があります。

コンソールで Aurora グローバルデータベースを表示すると、そのすべてのクラスターに関連付けられているすべての汎用エンドポイントを表示できます。次のスクリーンショットは、例を示しています。プライマリクラスターに関連付けられた単一のクラスターエンドポイントは、書き込みオペレーションに使用します。プライマリクラスターとセカンダリクラスターの読み取りエンドポイントは、読み取り専用クエリに使用します。レイテンシーを最小限にするには、貴社が存在している AWS リージョンまたは最寄りの AWS リージョンのリーダーエンドポイントを選択してください。次に Aurora MySQL の例を示します。


        AWS マネジメントコンソール にある Aurora グローバルデータベースおよび関連付けられた接続設定 (エンドポイント) を示すスクリーンショット。

Aurora グローバルデータベースのモニタリング

aurora_global_db_status() 関数 と aurora_global_db_instance_status() 関数を使用して、グローバルデータベースのステータスを表示します。

注記

Aurora PostgreSQL のみが、aurora_global_db_status() 関数および aurora_global_db_instance_status() 関数をサポートします。

グローバルデータベースをモニタリングするには

  1. psql などの PostgreSQL ユーティリティを使用して、グローバルデータベースのプライマリクラスターエンドポイントに接続します。接続方法の詳細については、「Aurora グローバルデータベースへの接続」を参照してください。

  2. psql コマンドで aurora_global_db_status() 関数を使用して、プライマリボリュームとセカンダリボリュームを一覧表示します。これは、グローバルデータベースのセカンダリ DB クラスターの遅延時間を示します。

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin ------------+---------------------+------------------------+-----------------+----------------------------+----------------+--------------- us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0 us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243 (2 rows)

    出力には、次の列を含むグローバルデータベースの各 DB クラスターの行が含まれます。

    • aws_region – この DB クラスターがある AWS リージョン。エンジン別の AWS リージョンの一覧表については、「 リージョンとアベイラビリティーゾーン」を参照してください。

    • highest_lsn_written – この DB クラスターに現在書き込まれているログシーケンス番号 (LSN) の最大値。

      ログシーケンス番号 (LSN) は、データベーストランザクションログ内のレコードを識別する一意の連続番号です。LSN は、より大きな LSN が後のトランザクションを表すように順序付けられます。

    • durability_lag_in_msec – セカンダリ DB クラスター (highest_lsn_written) に書き込まれた最大ログシーケンス番号とプライマリ DB クラスターに書き込まれた highest_lsn_written とのタイムスタンプ差。

    • rpo_lag_in_msec – リカバリポイント目標 (RPO) の遅れ。この遅延は、セカンダリ DB クラスターに保存された最新のユーザートランザクションコミットと、プライマリ DB クラスターに保存された最新のユーザートランザクションコミットの間の時間差です。

    • last_lag_calculation_timereplication_lag_in_msec および rpo_lag_in_msec に対して値が最後に計算されたタイムスタンプ。

    • feedback_epoch – セカンダリ DB クラスターがホットスタンバイ情報を生成するときに使用するエポック。

      ホットスタンバイとは、サーバーが復旧モードまたはスタンバイモードのときに DB クラスターが接続してクエリを実行できる場合です。ホットスタンバイのフィードバックは、ホットスタンバイの場合の DB クラスターに関する情報です。詳細については、ホットスタンバイの PostgreSQL ドキュメントを参照してください。

    • feedback_xmin – セカンダリ DB クラスターで使用される最小 (最も古い) のアクティブなトランザクション ID。

  3. aurora_global_db_instance_status() 関数を使用して、プライマリ DB クラスターとセカンダリ DB クラスターの両方のセカンダリ DB インスタンスをすべて一覧表示します。

    postgres=> select * from aurora_global_db_instance_status();
    server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec --------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------ apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | | apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10 apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017 (3 rows)

    出力には、次の列を含むグローバルデータベースの各 DB インスタンスの行が含まれます。

    • server_id – DB インスタンスのサーバー識別子。

    • session_id – 現在のセッションの一意の識別子。

    • aws_region – この DB インスタンスがある AWS リージョン。エンジン別の AWS リージョンの一覧表については、「 リージョンとアベイラビリティーゾーン」を参照してください。

    • durable_lsn – ストレージで耐久性のあるログシーケンス番号 (LSN)。

    • highest_lsn_rcvd – 書き込み DB インスタンスから DB インスタンスが受信した最高の LSN。

    • feedback_epoch – DB インスタンスがホットスタンバイ情報を生成するときに使用するエポック。

      ホットスタンバイとは、サーバーが復旧モードまたはスタンバイモードのときに DB インスタンスが接続してクエリを実行できる場合です。ホットスタンバイのフィードバックは、ホットスタンバイの場合の DB インスタンスに関する情報です。詳細については、ホットスタンバイの PostgreSQL ドキュメントを参照してください。

    • feedback_xmin – DB インスタンスで使用される最小 (最も古い) のアクティブなトランザクション ID。

    • oldest_read_view_lsn – ストレージから読み取るために DB インスタンスが使用する最も古い LSN。

    • visibility_lag_in_msec – この DB インスタンスが書き込み DB インスタンスからどのくらい遅れているか。

これらの値が時間の経過とともにどのように変化するかを確認するには、テーブルの挿入に 1 時間かかる次のトランザクションブロックを検討してください。

psql> BEGIN; psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; psql> COMMIT;

BEGIN ステートメントの後にプライマリ DB クラスターとセカンダリ DB クラスター間でネットワークが切断された場合、セカンダリ DB クラスター replication_lag_in_msec の値が増加し始めます。INSERT ステートメントの終了時は、replication_lag_in_msec 値は 1 時間です。ただし、プライマリ DB クラスターとセカンダリ DB クラスター間でコミットされたすべてのユーザーデータは同じであるため、rpo_lag_in_msec 値は 0 です。COMMIT ステートメントが完了すると、すぐに rpo_lag_in_msec 値が増加します。

Aurora グローバルデータベースのためのリージョン間の災害対策

場合によっては、Aurora グローバルデータベースに複数のセカンダリ AWS リージョンが含まれることがあります。その場合、停止がプライマリ AWS リージョンに影響する場合にフェイルオーバーする AWS リージョンを選択できます。選択する AWS リージョンを決定するために、すべてのセカンダリリージョンのレプリケーションラグをモニタリングできます。場合によっては、1 つのセカンダリリージョンが他のリージョンよりもレプリケーションの遅延が大幅に少なくなることがあります。その場合、関連付けられている Aurora クラスターに、アプリケーションの完全な読み取り/書き込みワークロードを引き継ぐのに十分なデータベースおよびネットワーク容量があることを示しています。

グローバルデータベースに複数のセカンダリリージョンがある場合、プライマリ AWS リージョンが停止したら、すべてのセカンダリリージョンをデタッチしてください。次に、これらのセカンダリリージョンの 1 つを新しいプライマリ AWS リージョンに昇格させます。最後に、他の各セカンダリリージョンに新しいクラスターを作成し、それらのクラスターをグローバルデータベースにアタッチします。

セカンダリクラスターをプライマリクラスターに昇格させる場合は、アプリケーションがグローバルデータベースへの接続に使用するエンドポイントも更新する必要があります。新しく昇格したクラスターから新しい書き込みエンドポイントを取得するには、エンドポイント文字列から -ro を削除することで、以前のリーダーエンドポイントを変換できます。たとえば、以前のリーダーエンドポイントが global-16rr-test-cluster-1.cluster-ro-12345678901.us-west-2.rds.amazonaws.com である場合、昇格された新しい書き込みエンドポイントは global-16rr-test-cluster-1.cluster-cps2igpwyrwa.us-west-2.rds.amazonaws.com です。

Aurora グローバルデータベースのフェイルオーバー

Aurora グローバルデータベースは、デフォルトの Aurora クラスターよりも高度なフェイルオーバー機能を提供します。特定の AWS リージョンでクラスター全体が使用不可になった場合は、グローバルデータベースの別のクラスターを昇格させて読み取り/書き込み機能を持たせることができます。

別の AWS リージョンにあるクラスターがプライマリクラスターとしてより適格である場合は、フェイルオーバー機能を手動で有効にすることができます。たとえば、セカンダリクラスターの 1 つの容量を増やして、プライマリクラスターに昇格させることができます。または、AWS リージョン間のアクティビティのバランスが変わる場合があり、プライマリクラスターを別の AWS リージョンに切り替えるほうが書き込みオペレーションのレイテンシーが低くなることがあります。

次の手順では、Aurora グローバルデータベース内のセカンダリクラスターの 1 つを昇格させる手順の概要を説明します。

セカンダリクラスターを昇格させるには

手順を開始する前に、プライマリクラスターに障害が発生するか、使用できなくなります。

  1. Aurora グローバルデータベースからセカンダリクラスターを解除します。そうすることで、クラスターは完全な読み取り/書き込み機能に昇格されます。グローバルデータベースから Aurora クラスターを解除する方法については、「Aurora グローバルデータベースからのクラスターの削除」を参照してください。

  2. 新しく昇格させたクラスターに書き込みトラフィックを振り向けるようにアプリケーションを設定し直します。

    重要

    この時点で、使用不可になったクラスターに対する DML ステートメントや他の書き込みオペレーションの発行を停止します。クラスター間のデータの不一致 (「スプリットブレイン」シナリオと呼ばれます) を避けるために、以前のプライマリクラスターには (それが再度オンラインになったとしても) 書き込まないでください。

  3. 新しく昇格させたクラスターをプライマリクラスターとして新しい Aurora グローバルデータベースを作成します。Aurora グローバルデータベースの作成方法については、「Aurora グローバルデータベースの作成」を参照してください。

  4. Aurora グローバルデータベースに、問題が発生したクラスターの AWS リージョンを追加します。この AWS リージョンに新しいセカンダリクラスターを含めます。AWS リージョンを Aurora グローバルデータベースに追加する方法については、「Aurora グローバルデータベースへの AWS リージョンの追加」を参照してください。

  5. 停止状態が解決されて元の AWS リージョンをプライマリクラスターとして再度割り当てる準備が完了したら、同じステップを逆に実行します。

    1. Aurora グローバルデータベースからセカンダリクラスターの 1 つを解除します。

    2. このクラスターを、元の AWS リージョンで新しい Aurora グローバルデータベースのプライマリクラスターにします。

    3. 元の AWS リージョンのプライマリクラスターにすべての書き込みトラフィックをリダイレクトします。

    4. AWS リージョンを追加し、前と同じ AWS リージョンに 1 つ以上のセカンダリクラスターをセットアップします。

Aurora グローバルデータベースの復旧の管理

プライマリ DB クラスターに影響するネットワークやハードウェアなどに障害が発生した場合に、グローバルデータベースが再開されるポイントを制御できます。復旧を管理するには、グローバルデータベースの RPO (目標復旧時点) を設定します。

注記

RPO の管理は、現在 PostgreSQL との互換性がある Amazon Aurora でサポートされています。サポートされている Aurora PostgreSQL バージョンと AWS リージョンのリストについては、「Aurora グローバルデータベースの制限」を参照してください。

目標復旧時点とは、セカンダリ DB クラスターから復旧できるデータの最も古い期間です。RPO は、フェイルオーバー後にデータベースが新しい AWS リージョンでオペレーションを再開するときに使用されます。これは、データベースのフェイルオーバーで受け入れることができる時間単位のデータ損失量を表します。

マネージド RPO を使用すると、セカンダリ DB クラスターがプライマリ DB クラスターよりも遅れているため、データ損失の最大量を制御できます。このデータ損失は時間単位で測定され、 RPO ラグタイムと呼ばれます。 RPO を設定すると、次のように Aurora PostgreSQL がグローバルデータベースでこれを強制します。

  1. Aurora PostgreSQL では、少なくとも 1 つのセカンダリ DB クラスターの RPO 遅延時間が RPO 時間よりも短い場合に、プライマリ DB クラスターでトランザクションをコミットできます。

  2. Aurora PostgreSQL は、RPO 遅延時間が RPO 時間よりも短いセカンダリ DB クラスターがない場合、トランザクションコミットをブロックします。Aurora PostgreSQL がコミットのブロックを開始すると、PostgreSQL ログファイルにイベントが挿入されます。次に、ブロックされたセッションを示す待機イベントを発行します。

  3. Aurora PostgreSQL では、少なくとも 1 つのセカンダリ DB クラスターの RPO ラグタイムが RPO 時間より短くなった場合に、プライマリ DB クラスターでトランザクションを再度コミットできます。

この方法により、Aurora PostgreSQL では、選択した RPO 時間に違反するトランザクションコミットが完了することを許可しません。

目標復旧時点の表示

グローバルデータベースの RPO (目標復旧時点) は、rds.global_db_rpo パラメータに保存されます。クラスターパラメータグループの rds.global_db_rpo パラメータとその他のパラメータの現在の RPO 設定を表示するには、「DB クラスターパラメータグループのパラメータ値を表示する」を参照してください。

目標復旧時点の設定

グローバルデータベースの RPO は、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して設定できます。詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

コンソールを使用して RPO を設定するには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. グローバルデータベースのプライマリ DB クラスターのパラメータグループを指定します。クラスターの設定の詳細については、「Aurora グローバルデータベースの設定」を参照してください。

  3. プライマリ DB クラスターパラメータグループを開き、[rds.global_db_rpo] パラメータを設定します。詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

  4. [rds.global_db_rpo] パラメータ値を、目標復旧ポイントの秒数に設定します。有効な値は、20 秒から最大整数値 2,147,483,647 (68 年) までです。

rds.global_db_rpo パラメータを設定するには、AWS CLI を使用し、modify-db-cluster-parameter-group コマンドを使用します。

次の例では、global_db_cluster_parameter_group という名前のプライマリ DB クラスターパラメータグループの RPO を 5,000 秒に設定します。有効な値は、20 秒から最大整数値 2,147,483,647 (68 年) までです。

Linux、macOS、Unix の場合:

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

Windows の場合:

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

rds.global_db_rpo パラメータを変更するには、Amazon RDS ModifyDBClusterParameterGroup API オペレーションを使用します。

目標復旧時点の無効化

RPO を無効にするには、rds.global_db_rpo パラメータをリセットします。AWS マネジメントコンソール、AWS CLI、または RDS API を使用してパラメータをリセットできます。

コンソールを使用して RPO を無効にするには

  1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[パラメータグループ] を選択します。

  3. リストで、プライマリ DB クラスターパラメータグループを選択します。

  4. [Edit parameters] を選択します。

  5. [rds.global_db_rpo] パラメータの横にあるボックスを選択します。

  6. [リセット] を選択します。

  7. 画面に [Reset parameters in DB parameter group (DB パラメータグループのパラメータのリセット)] が表示されたら、[Reset parameters (パラメータのリセット)] を選択します。

コンソールでパラメータをリセットする方法の詳細については、「DB クラスターパラメータグループのパラメータの変更」を参照してください。

rds.global_db_rpo パラメータをリセットするには、reset-db-cluster-parameter-group コマンドを使用します。

Linux、macOS、Unix の場合:

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"

Windows の場合:

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"

rds.global_db_rpo パラメータをリセットするには、Amazon RDS API ResetDBClusterParameterGroup オペレーションを使用します。

Aurora グローバルデータベースの Performance Insights

Amazon RDS Performance Insights と Aurora グローバルデータベースは一緒に使用することができます。一緒に使用した場合、Performance Insights レポートはグローバルデータベース内の各クラスターに個別に適用されます。グローバルデータベースの一部である各クラスターに対して Performance Insights を有効または無効にすることができます。すでに Performance Insights を使用しているグローバルデータベースに新しいセカンダリ AWS リージョンを追加するときは、新しく追加したクラスターで Performance Insights を有効にする必要があります。既存のグローバルデータベースから Performance Insights 設定が継承されることはありません。

グローバルデータベースにアタッチされている DB インスタンスの Performance Insights ページを表示しながら、AWS リージョンを切り替えることができます。ただし、AWS リージョンを切り替えた直後は、パフォーマンス情報が表示されない場合があります。DB インスタンスの名前が AWS の各リージョンで同じ場合がありますが、関連付けられている Performance Insights の URL は DB インスタンスごとに異なります。AWS リージョンを切り替えたら、Performance Insights のナビゲーションペインで DB インスタンスの名前をもう一度選択します。

グローバルデータベースに関連付けられている DB インスタンスの場合、パフォーマンスに影響を与える要因は AWS の各リージョンで異なる場合があります。たとえば、各 AWS リージョンの DB インスタンスのキャパシティーは異なります。

Performance Insights の使用については、「Amazon RDSパフォーマンスインサイトの使用」を参照してください。

Aurora グローバルデータベースと AWS の他のサービスの併用

Aurora グローバルデータベースと一緒に AWS の他のサービスを利用する場合があります。このような場合は、すべての関連付けられたクラスターの対応する AWS リージョンで、同じ特権や外部関数などが必要です。グローバルデータベースの Aurora クラスターは、最初は読み取り専用レプリケーションターゲットであっても、後でプライマリクラスターに昇格させる可能性があります。この可能性に備えて、グローバルデータベースのすべての Aurora クラスターで、事前に他のサービスに必要な書き込み特権をセットアップしておきます。

以下のリストは、AWS のサービスごとに行うセットアップの概要です。

Lambda 関数を呼び出す

Aurora グローバルデータベースを構成するすべての Aurora クラスターで、「Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し」の手順を実行します。

Aurora グローバルデータベースのクラスターごとに aws_default_lambda_role パラメータを新しい IAM ロールの Amazon リソースネーム (ARN) に設定します。

Aurora グローバルデータベースのデータベースユーザーに Lambda 関数を呼び出すことを許可するには、「Amazon Aurora から AWS のサービスにアクセスすることを許可する IAM ロールの作成」で作成したロールを Aurora グローバルデータベースの各クラスターに関連付けます。

Lambda へのアウトバウンド接続を許可するように Aurora グローバルデータベースの各クラスターを設定します。手順については、「Amazon Aurora MySQL から AWS の他のサービスへのネットワーク通信の有効化」を参照してください。

S3 からデータをロードする

Aurora グローバルデータベースを構成するすべての Aurora クラスターで、「Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード」の手順を実行します。

グローバルデータベースの Aurora クラスターごとに、DB クラスターの aurora_load_from_s3_role パラメータまたは aws_default_s3_role パラメータを新しい IAM ロールの Amazon リソースネーム (ARN) に設定します。IAM ロールが aurora_load_from_s3_role に指定されていない場合、Aurora は aws_default_s3_role に指定されている IAM ロールを使用します。

Aurora グローバルデータベースのデータベースユーザーに Amazon S3 を呼び出すことを許可するには、「Amazon Aurora から AWS のサービスにアクセスすることを許可する IAM ロールの作成」で作成したロールを、グローバルデータベースの各 Aurora クラスターに関連付けます。

Amazon S3 へのアウトバウンド接続を許可するようにグローバルデータベースの各 Aurora クラスターを設定します。手順については、「Amazon Aurora MySQL から AWS の他のサービスへのネットワーク通信の有効化」を参照してください。

クエリのデータを S3 に保存する

Aurora グローバルデータベースを構成するすべての Aurora クラスターで、「Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存」の手順を実行します。

グローバルデータベースの Aurora クラスターごとに、DB クラスターの aurora_select_into_s3_role パラメータまたは aws_default_s3_role パラメータを新しい IAM ロールの Amazon リソースネーム (ARN) に設定します。IAM ロールが aurora_select_into_s3_role に指定されていない場合、Aurora は aws_default_s3_role に指定されている IAM ロールを使用します。

Aurora グローバルデータベースのデータベースユーザーに Amazon S3 を呼び出すことを許可するには、「Amazon Aurora から AWS のサービスにアクセスすることを許可する IAM ロールの作成」で作成したロールを、グローバルデータベースの各 Aurora クラスターに関連付けます。

Amazon S3 へのアウトバウンド接続を許可するようにグローバルデータベースの各 Aurora クラスターを設定します。手順については、「Amazon Aurora MySQL から AWS の他のサービスへのネットワーク通信の有効化」を参照してください。