Amazon Aurora グローバルデータベースの書き込み転送を使用する

書き込み転送を使用すると Aurora グローバルデータベースで実行されているアプリケーションで管理すべきエンドポイントの数を、減らすことができます。この Aurora MySQL の機能により、Aurora グローバルデータベースのセカンダリクラスターは、書き込み操作を実行する SQL 文をプライマリクラスターに転送することができます。プライマリクラスターがソースを更新し、結果の変更をすべてのセカンダリ AWS リージョンに反映させます。

書き込み転送設定は、書き込み操作を送信する独自のメカニズムをセカンダリ AWS リージョンからプライマリリージョンに実装しないようにするのに役立ちます。Aurora は、クロスリージョンネットワークの設定を処理します。Aurora は、各ステートメントに必要なすべてのセッションおよびトランザクションコンテキストも送信します。データは常に、最初にプライマリクラスターで変更され、次に Aurora グローバルデータベースのセカンダリクラスターにレプリケートされます。このようにして、プライマリクラスターは、すべてのデータの最新のコピーを持つ、常に信頼できる情報源となります。

注記

書き込み転送には Aurora MySQL バージョン 2.08.1 以降が必要です。

書き込み転送の有効化

デフォルトでは、セカンダリクラスターを Aurora グローバルデータベースに追加すると、書き込み転送は有効になりません。

AWS マネジメントコンソール を使用して書き込み転送を有効にするには、グローバルデータベースに対して [リージョンの追加] アクションを実行するときに、[リードレプリカ書き込み転送を有効にする] オプションを選択します。既存のセカンダリクラスターの場合は、[リードレプリカ書き込み転送を有効にする] オプションを使用するようにクラスターを変更します。書き込み転送をオフにするには、リージョンの追加時またはセカンダリクラスターの変更時に [リードレプリカ書き込み転送を有効にする] チェックボックスをオフにします。

AWS CLI を使用して書き込み転送を有効にするには、--enable-global-write-forwarding オプションを使用します。このオプションは、create-db-cluster コマンドを使用して新しいセカンダリクラスターを作成するときに機能します。modify-db-cluster コマンドを使用して、既存のセカンダリクラスターを変更する場合にも機能します。グローバルデータベースでは、書き込み転送をサポートする Aurora バージョンを使用する必要があります。これらの同じ CLI コマンドで --no-enable-global-write-forwarding オプションを使用すると、書き込み転送をオフにすることができます。

Amazon RDS API を使用して書き込み転送を有効にするには、EnableGlobalWriteForwarding パラメータを true に設定します。このパラメータは、CreateDBCluster オペレーションを使用して新しいセカンダリクラスターを作成するときに機能します。この操作は、ModifyDBCluster オペレーションを使用して既存のセカンダリクラスターを変更する場合にも機能します。グローバルデータベースでは、書き込み転送をサポートする Aurora バージョンを使用する必要があります。EnableGlobalWriteForwarding パラメータを false に設定することで、書き込み転送をオフにすることができます。

注記

データベースセッションで書き込み転送を利用するには、aurora_replica_read_consistency 設定パラメータの設定も指定してください。書き込み転送機能を使用するすべてのセッションでこれを行います。このパラメータの詳細については、「書き込み転送の分離と整合性」を参照してください。

次の CLI の例は、書き込み転送を有効または無効にして Aurora グローバルデータベースを設定する方法を示しています。強調表示された項目は、Aurora グローバルデータベースのインフラストラクチャをセットアップするときに指定し、一貫性を保つために重要なコマンドとオプションを表しています。

次の例では、書き込み転送が有効になっている Aurora グローバルデータベース、プライマリクラスター、およびセカンダリクラスターを作成します。ユーザー名、パスワード、プライマリとセカンダリの AWS リージョンは、自分で選択したものに置き換えます。

# Create overall global database.
aws rds create-global-cluster --global-cluster-identifier write-forwarding-test \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-1

# Create primary cluster, in the same AWS Region as the global database.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-1 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --master-username my_user_name --master-user-password my_password \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-1

# Create secondary cluster, in a different AWS Region than the global database,
# with write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-2 \
  --enable-global-write-forwarding

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-2

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-east-2

次の例は、前の例から続きます。書き込み転送が有効になっていないセカンダリクラスターを作成し、書き込み転送を有効にします。この例が終了すると、グローバルデータベース内のすべてのセカンダリクラスターで書き込み転送が有効になります。

# Create secondary cluster, in a different AWS Region than the global database,
# without write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.08.1 \
  --region us-west-1

aws rds modify-db-cluster --db-cluster-identifier write-forwarding-test-cluster-2 \
  --region us-east-2 \
  --enable-global-write-forwarding

セカンダリクラスターで書き込み転送が有効になっているかどうかの確認

セカンダリクラスターからの書き込み転送を使用できるかどうかを判断するには、クラスターに属性 "GlobalWriteForwardingStatus": "enabled" があるかどうかを確認します。

AWS マネジメントコンソール では、クラスターの詳細ページの [設定] タブに Read replica write forwarding が表示されます。すべてのクラスターのグローバル書き込み転送設定のステータスを表示するには、次の AWS CLI コマンドを実行します。

セカンダリクラスターには、書き込み転送がオンかオフかを示す値 "enabled" または "disabled" が表示されます。値 null は、そのクラスターで書き込み転送が使用できないことを示します。クラスターがグローバルデータベースの一部ではないか、セカンダリクラスターではなくプライマリクラスターです。書き込み転送をオンまたはオフにする処理中の場合、値は "enabling" または "disabling" になります。

例

aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    },
    {
        "GlobalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
    },
    {
        "GlobalWriteForwardingStatus": null,
        "DBClusterIdentifier": "non-global-cluster"
    }
]

グローバル書き込み転送が有効になっているすべてのセカンダリクラスターを検索するには、次のコマンドを実行します。このコマンドは、クラスターのリーダーエンドポイントも返します。Aurora グローバルデータベースでセカンダリからプライマリへの書き込み転送を使用するときは、セカンダリクラスターのリーダーエンドポイントを使用します。

例

aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    }
]

書き込み転送とアプリケーションおよび SQL の互換性

特定のステートメントは、書き込み転送機能を持つグローバルデータベースで使用すると、許可されないか、または古い結果を生成する可能性があります。したがって、セカンダリクラスターで EnableGlobalWriteForwarding の設定はデフォルトではオフになっています。オンにする前に、アプリケーションコードがこれらの制限の影響を受けていないことを確認してください。

書き込み転送では、次の種類の SQL ステートメントを使用できます。

• INSERT、DELETE、および UPDATE などのデータ操作言語 (DML) ステートメント。書き込み転送で使用できるこれらのステートメントのプロパティには、以下で説明するように、いくつかの制限があります。

• SELECT ... LOCK IN SHARE MODE と SELECT FOR UPDATE ステートメント。

• PREPARE と EXECUTE ステートメント。

書き込み転送で使用する SQL ステートメントには、次の制限が適用されます。場合によっては、書き込み転送がクラスターレベルで有効になっているセカンダリクラスターでステートメントを使用できます。この方法は、aurora_replica_read_consistency 設定パラメータによってセッション内で書き込み転送がオンになっていない場合に機能します。書き込み転送のために許可されていないステートメントを使用しようとすると、次の形式のエラーメッセージが表示されます。

ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.

データ定義言語 (DDL)

プライマリクラスターに接続して、このようなステートメントを実行します。

一時テーブルのデータを使用した永続テーブルの更新

書き込み転送が有効になっているセカンダリクラスターでは、一時テーブルを使用できます。ただし、ステートメントが一時テーブルを参照している場合は、DML ステートメントを使用して永続テーブルを変更することはできません。たとえば、一時テーブルからデータを取る INSERT ... SELECT ステートメントを使用することはできません。一時テーブルはセカンダリクラスターに存在し、プライマリクラスターでステートメントを実行するときには使用できません。

XA トランザクション

セッション内で書き込み転送が有効になっている場合、セカンダリクラスターで次のステートメントを使用することはできません。これらのステートメントは、書き込み転送が有効になっていないセカンダリクラスター、または aurora_replica_read_consistency 設定が空のセッションで使用できます。セッション内で書き込み転送を有効にする前に、コードでこれらのステートメントが使用されているかどうかを確認してください。

XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER [CONVERT XID]

永続テーブルの LOAD ステートメント

書き込み転送が有効になっているセカンダリクラスターでは、次のステートメントを使用できません。

        LOAD DATA INFILE 'data.txt' INTO TABLE t1;
        LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;

セカンダリクラスターの一時テーブルにデータをロードできます。ただし、永続テーブルを参照する LOAD ステートメントは、プライマリクラスターでのみ実行してください。

プラグインステートメント

書き込み転送が有効になっているセカンダリクラスターでは、次のステートメントを使用できません。

INSTALL PLUGIN example SONAME 'ha_example.so';
UNINSTALL PLUGIN example;

SAVEPOINT ステートメント

セッション内で書き込み転送が有効になっている場合、セカンダリクラスターで次のステートメントを使用することはできません。これらのステートメントは、書き込み転送が有効になっていないセカンダリクラスター、または aurora_replica_read_consistency 設定が空白のセッションで使用できます。セッション内で書き込み転送を有効にする前に、コードでこれらのステートメントが使用されているかどうかを確認してください。

SAVEPOINT t1_save;
ROLLBACK TO SAVEPOINT t1_save;
RELEASE SAVEPOINT t1_save;

書き込み転送の分離と整合性

書き込み転送を使用するセッションでは、REPEATABLE READ 分離レベルのみを使用できます。セカンダリ AWS リージョンの読み取り専用クラスターでも READ COMMITTED 分離レベルを使用できますが、その分離レベルは書き込み転送では機能しません。REPEATABLE READ および READ COMMITTED 分離レベルの詳細については、「Aurora MySQL の分離レベル」を参照してください。

セカンダリクラスターの読み取り整合性の程度を制御できます。読み取り整合性レベルは、一部またはすべての変更がプライマリクラスターからレプリケートされるように、各読み取りオペレーションの前にセカンダリクラスターが実行する待機時間を決定します。読み取り整合性レベルを調整して、セッションから転送されたすべての書き込みオペレーションが、後続のクエリの前にセカンダリクラスターに表示されるようにすることができます。この設定を使用して、セカンダリクラスターのクエリに、他のセッションや他のクラスターから送信された更新も含め、常にプライマリクラスターからの最新の更新が表示されるようにすることもできます。アプリケーションでこの種類の動作を指定するには、セッションレベルのパラメータ aurora_replica_read_consistency の値を選択します。

重要

書き込み転送を使用する各セッションで aurora_replica_read_consistency パラメータを設定してください。それ以外の場合、Aurora はそのセッションの書き込み転送を有効にしません。このパラメータのデフォルト値は空です。有効にするには、特定の値を選択します。この aurora_replica_read_consistency パラメータは、書き込み転送が有効になっているセカンダリクラスターでのみ有効です。

aurora_replica_read_consistency パラメータには、EVENTUAL、SESSION、および GLOBAL の値を指定できます。

整合性レベルを上げると、アプリケーションは、AWS リージョン間で変更が反映されるのを待つ時間が長くなります。応答時間の短縮と、クエリを実行する前に他の場所で行われた変更が完全に使用可能であることのバランスを選択できます。

読み取り整合性を EVENTUAL に設定した場合、書き込み転送を使用するセカンダリ AWS リージョンのクエリでは、レプリケーションの遅延によりデータがわずかに古くなることがあります。同じセッションでの書き込みオペレーションの結果は、プライマリリージョンで書き込みオペレーションが実行され、現在のリージョンにレプリケートされるまで表示されません。クエリは、更新された結果が使用可能になるのを待つことはありません。したがって、ステートメントのタイミングとレプリケーションの遅延の量に応じて、古いデータや更新されたデータが取得される可能性があります。

読み取り整合性を SESSION に設定した場合、書き込み転送を使用するセカンダリ AWS リージョンのすべてのクエリに、そのセッションで行われたすべての変更の結果が表示されます。トランザクションがコミットされているかどうかにかかわらず、変更が表示されます。必要に応じて、クエリは、転送された書き込みオペレーションの結果が現在のリージョンにレプリケートされるまで待機します。他のリージョンまたは現在のリージョン内の他のセッションで実行された書き込みオペレーションの結果が更新されるのを待つことはありません。

読み取り整合性を GLOBAL に設定した場合、セカンダリ AWS リージョンのセッションには、そのセッションによって行われた変更が表示されます。また、プライマリ AWS リージョンと他のセカンダリ AWS リージョンの両方のコミットされた変更もすべて表示されます。各クエリは、セッション遅延の量に応じて変化する期間を待つことがあります。クエリは、クエリが開始された時点の、プライマリクラスターからコミットされたすべてのデータでセカンダリクラスターが最新の状態になったときに実行されます。

書き込み転送に関連するすべてのパラメータの詳細については、「書き込み転送の設定パラメータ」を参照してください。

書き込み転送の使用例

この例では、プライマリクラスターは AWS リージョン 米国東部（バージニア北部） にあります。セカンダリクラスターは AWS リージョン 米国東部 (オハイオ) にあります。この例は、INSERT ステートメントの後に SELECT ステートメントが続いて実行された場合の結果を示しています。aurora_replica_read_consistency 設定値によっては、ステートメントのタイミングによって結果が異なる場合があります。整合性を高めるには、SELECT ステートメントを発行する前にしばらく待つか、Aurora が結果のレプリケーションが完了するまで自動的に待機してから、SELECT に進みます。

この例では、読み取り整合性設定が eventual の場合、INSERT ステートメントの直後に SELECT ステートメントを実行すると、新しいローが挿入される前のローの数を反映する値 COUNT(*) が返されます。しばらくしてから SELECT を再度実行すると、更新された行数が返されます。SELECT ステートメントは待機しません。

mysql> set aurora_replica_read_consistency = 'eventual';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)
mysql> insert into t1 values (6); select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

読み取り整合性設定が session の場合、INSERT の直後の SELECT ステートメント は、INSERT ステートメントからの変更が表示されるまで待機します。後続の SELECT ステートメントは待機しません。

mysql> set aurora_replica_read_consistency = 'session';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.01 sec)
mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1;
Query OK, 1 row affected (0.08 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.37 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)

読み取り整合性設定を session に設定したまま、INSERT ステートメントの実行後に短い待機を行うと、次の SELECT ステートメントが実行されるまでに更新された行カウントが使用可能になります。

mysql> insert into t1 values (6); select sleep(2); select count(*) from t1;
Query OK, 1 row affected (0.07 sec)
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.01 sec)
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.00 sec)

読み取り整合性設定が global の場合、各 SELECT ステートメントは、クエリを実行する前に、ステートメントの開始時刻時点のすべてのデータ変更が表示されるように待機します。各 SELECT ステートメントの待機時間は、プライマリクラスターとセカンダリクラスター間のレプリケーション遅延の量によって異なります。

mysql> set aurora_replica_read_consistency = 'global';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.75 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.37 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.66 sec)

書き込み転送を使用したマルチパートステートメントの実行

DML ステートメントは、INSERT ... SELECT ステートメントや DELETE ... WHERE ステートメントなど、複数の部分から構成される場合があります。この場合、ステートメント全体がプライマリクラスターに転送され、そこで実行されます。

書込み転送を使用したトランザクション

トランザクションがプライマリクラスターに転送されるかどうかは、トランザクションのアクセスモードによって異なります。SET TRANSACTION ステートメントまたは START TRANSACTION ステートメントを使用して、トランザクションのアクセスモードを指定できます。Aurora MySQL セッション変数 tx_read_only の値を変更することで、トランザクションアクセスモードを指定することもできます。このセッション値は、書き込み転送が有効になっているセカンダリクラスターに接続しているときにのみ変更できます。

長時間実行されるトランザクションがかなりの期間ステートメントを発行しない場合、アイドルタイムアウト期間を超える可能性があります。この期間のデフォルトは 1 分です。1 日まで増やすことができます。アイドルタイムアウトを超えたトランザクションは、プライマリクラスターによってキャンセルされます。次に送信するステートメントは、タイムアウトエラーを受け取ります。その後、Aurora はトランザクションをロールバックします。

このタイプのエラーは、書き込み転送が使用できなくなった場合に発生する可能性があります。たとえば、プライマリクラスターを再起動するか、書き込み転送構成設定を無効にした場合、Aurora は書き込み転送を使用するすべてのトランザクションをキャンセルします。

書き込み転送の設定パラメータ

Aurora クラスターパラメータグループには、書き込み転送機能のいくつかの新しい設定が含まれています。これらはクラスターパラメータであるため、各クラスターのすべての DB インスタンスは、これらの変数に同じ値を持ちます。セカンダリクラスターからの着信書き込みリクエストを制御するには、プライマリクラスターで次の設定を使用します。

• aurora_fwd_master_max_connections_pct: リーダーから転送されたクエリを処理するためにライター DB インスタンスで使用できるデータベース接続の上限。これは、プライマリクラスター内の書き込み DB インスタンスの max_connections 設定のパーセンテージで表されます。たとえば、max_connections が 800、aurora_fwd_master_max_connections_pct が 10 の場合、書き込みは最大 80 の同時転送セッションを許可します。これらの接続は、max_connections 設定によって管理される同じ接続プールから取得されます。

  この設定は、1 つ以上のセカンダリクラスターで書き込み転送が有効になっている場合に、プライマリクラスターにのみ適用されます。この値を小さくしても、既存の接続は影響を受けません。Aurora は、セカンダリクラスターから新しい接続を作成するときに、設定の新しい値を考慮します。デフォルト値は 10 で、max_connections 値の 10% を表します。セカンダリクラスターのいずれかでクエリ転送を有効にする場合、セカンダリクラスターからの書き込みオペレーションを正常に実行するには、この設定に 0 以外の値を指定する必要があります。値が 0 の場合、書き込みオペレーションは、メッセージ Not enough connections on master to handle your request とともにエラーコード ER_CON_COUNT_ERROR を受け取ります。

• aurora_fwd_master_idle_timeout: プライマリクラスターがセカンダリクラスターから転送された接続でアクティビティを終了するまで待機する秒数。この期間を超えてセッションがアイドル状態のままである場合、Aurora はセッションをキャンセルします。

次の新しいパラメータは、セッションレベルのパラメータです。

• aurora_replica_read_consistency: 書き込み転送を有効にする値。書き込み転送が行われるようにするには、各セッションで書き込み転送を設定します。詳細については、「書き込み転送の分離と整合性」を参照してください。

  読み取り整合性のレベルを指定します。次のいずれかの値を指定できます。

  • EVENTUAL

  • SESSION

  • GLOBAL

  整合性レベルの意味については、「書き込み転送の分離と整合性」を参照してください。

  このパラメータには、次の規則が適用されます。

  • これはセッションレベルのパラメータです。デフォルト値は '' (空) です。

  • 書き込み転送は、aurora_replica_read_consistency が EVENTUAL、SESSION、または GLOBAL に設定されている場合にのみセッションで使用できます。このパラメータは、書き込み転送が有効で、Aurora グローバルデータベース内にあるセカンダリクラスターの読み取りインスタンスでのみ関係します。

  • マルチステートメントトランザクション内では、この変数を設定する (空の場合) または設定解除する (既に設定されている場合) ことはできません。ただし、トランザクション中に、有効な値 (EVENTUAL、SESSION、GLOBAL) から別の値 (EVENTUAL、SESSION、GLOBAL) に変更することは可能です。

  • セカンダリクラスターで書き込み転送が有効になっていない場合、変数は SET に指定できません。

  • プライマリクラスターでセッション変数を設定しても、効果はありません。プライマリクラスターでこの変数を変更しようとすると、エラーが発生します。

次の表に、これらのパラメータの詳細を示します。

名前	スコープ	タイプ	デフォルト値	有効な値
aurora_replica_read_consistency	セッション	列挙型	''	EVENTUAL、SESSION、GLOBAL
aurora_fwd_master_max_connections_pct	グローバル	符号なし長整数	10	0–90
aurora_fwd_master_idle_timeout	グローバル	符号なし整数	60	1–86,400

書き込み転送の Amazon CloudWatch メトリクス

次の Amazon CloudWatch メトリクスは、1 つ以上のセカンダリクラスターで書き込み転送を使用する場合、プライマリクラスターに適用されます。これらのメトリクスはすべて、プライマリクラスターのライター DB インスタンスで測定されます。

メトリクス	Aurora MySQL ステータス変数	説明	単位
ForwardingMasterDMLLatency		書き込み DB インスタンスで転送された各 DML ステートメントを処理する平均時間。セカンダリクラスターが書き込みリクエストを転送する時間は含まれません。また、変更をセカンダリクラスターにレプリケートする時間も含まれません。	Milliseconds
ForwardingMasterOpenSessions	Aurora_fwd_master_open_sessions	書き込み DB インスタンスで転送されたセッションの数。	カウント
ForwardingMasterDMLThroughput		この書き込み DB インスタンスによって 1 秒間に処理される、転送された DML ステートメントの数。	1 秒あたりのカウント数
	Aurora_fwd_master_dml_stmt_duration	この書き込み DB インスタンスに転送された DML ステートメントの合計期間。	Microseconds
	Aurora_fwd_master_dml_stmt_count	この書き込み DB インスタンスに転送された DML ステートメントの合計数。
	Aurora_fwd_master_select_stmt_duration	この書き込み DB インスタンスに転送された SELECT ステートメントの合計期間。	Microseconds
	Aurora_fwd_master_select_stmt_count	この書き込み DB インスタンスに転送された SELECT ステートメントの総数。

次の CloudWatch メトリクスは、各セカンダリクラスターに適用されます。これらのメトリクスは、書き込み転送が有効になっているセカンダリクラスターの各読み取り DB インスタンスで測定されます。

メトリクス	Aurora MySQL ステータス変数	説明	単位
ForwardingReplicaDMLLatency		レプリカ上で転送された DML の平均応答時間 (ミリ秒)。	Milliseconds
ForwardingReplicaReadWaitLatency		読み取り DB インスタンス上の SELECT ステートメントがプライマリクラスターに追いつくのを待機する平均待機時間 (ミリ秒)。クエリを処理する前に読み取り DB インスタンスが待機する程度は、aurora_replica_read_consistency 設定によって異なります。	Milliseconds
ForwardingReplicaDMLThroughput		1 秒あたりに処理された転送 DML ステートメントの数。	1 秒あたりのカウント数
ForwardingReplicaReadWaitThroughput		書き込み転送が有効になっているセッションで 1 秒あたりに処理される SELECT ステートメントの数。	1 秒あたりのカウント数
ForwardingReplicaOpenSessions	Aurora_fwd_replica_open_sessions	読み取り DB インスタンスで書き込み転送を使用しているセッションの数。	カウント
	Aurora_fwd_replica_dml_stmt_count	この読み取り DB インスタンスから転送された DML ステートメントの合計数。
	Aurora_fwd_replica_dml_stmt_duration	この読み取り DB インスタンスから転送された DML ステートメントの合計期間。	Microseconds
	Aurora_fwd_replica_select_stmt_duration	この読み取り DB インスタンスから転送された SELECT ステートメントの合計期間。	Microseconds
	Aurora_fwd_replica_select_stmt_count	この読み取り DB インスタンスから転送された SELECT ステートメントの合計数。
	Aurora_fwd_replica_read_wait_duration	この読み取り DB インスタンスの読み取り整合性設定による待機時間の合計。	Microseconds
	Aurora_fwd_replica_read_wait_count	この読み取り DB インスタンスでの書き込み後の読み取り待機の合計数。
	Aurora_fwd_replica_errors_session_limit	エラー条件 master full または Too many forwarded statements in progress が原因でプライマリクラスターが拒否したセッションの数。