Aurora PostgreSQL グローバルデータベースで書き込み転送を使用する
トピック
- Aurora PostgreSQL での書き込み転送を利用できるリージョンとバージョン
- Aurora PostgreSQL での書き込み転送の有効化
- セカンダリクラスターで Aurora PostgreSQL での書き込み転送が有効になっているかどうかの確認
- 書き込み転送とアプリケーションおよび Aurora PostgreSQL の互換性
- Aurora PostgreSQL での書き込み転送の分離と整合性
- Aurora PostgreSQL での書き込み転送を使用したマルチパートステートメントの実行
- Aurora PostgreSQL での書き込み転送の設定パラメータ
- Aurora PostgreSQL での書き込み転送の Amazon CloudWatch メトリクス
- Aurora PostgreSQL での書き込み転送のイベントを待機する
Aurora PostgreSQL での書き込み転送を利用できるリージョンとバージョン
書き込み転送は、Aurora PostgreSQL バージョン 15.4 以降のマイナーバージョンと、バージョン 14.9 以降のマイナーバージョンでサポートされます。書き込み転送は、Aurora PostgreSQL ベースのグローバルデータベースが利用可能なすべてのリージョンで利用できます。
Aurora PostgreSQL グローバルデータベースで利用できるバージョンとリージョンについては、「Aurora PostgreSQL を使用した Aurora グローバルデータベース」を参照してください。
Aurora PostgreSQL での書き込み転送の有効化
デフォルトでは、セカンダリクラスターを Aurora Global Database に追加すると、書き込み転送は有効になりません。セカンダリ DB クラスターの書き込み転送は、作成中または作成後にいつでも有効にできます。必要に応じて、後で無効にすることができます。書き込み転送を有効または無効にしても、ダウンタイムや再起動は発生しません。
コンソールでは、セカンダリ DB クラスターを作成または変更するときに、書き込み転送を有効または無効にすることができます。
セカンダリ DB クラスターの作成時に書き込み転送を有効または無効にする
新しいセカンダリ DB クラスターを作成するときは、[リードレプリカの書き込み転送] の [グローバル書き込み転送を有効にする] チェックボックスをオンにして、書き込み転送を有効にします。または、チェックボックスをオフにしてこの機能を無効にします。セカンダリ DB クラスターを作成するには、「Amazon Aurora DB クラスターの作成」の DB エンジンの手順に従ってください。
次のスクリーンショットは、[グローバル書き込み転送を有効にする] チェックボックスがオンになっている[リードレプリカの書き込み転送] セクションを示しています。
セカンダリ DB クラスターの修正時に書き込み転送を有効または無効にする
コンソールでは、セカンダリ DB クラスターを修正して書き込み転送を有効または無効にすることができます。
コンソールでセカンダリ DB クラスターの書き込み転送を有効または無効にするには
AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/
を開きます。 -
[データベース] をクリックします。
-
セカンダリ DB クラスターを選択し、[変更] を選択します。
-
[リードレプリカの書き込み転送] セクションで、[グローバル書き込み転送を有効にする] チェックボックスをオンまたはオフにします。
-
[Continue] (続行) をクリックします。
-
[変更をスケジュール] で、[すぐに適用] を選択します。次に [スケジュールされたメンテナンスウィンドウで適用] を選択すると、Aurora ではこの設定が無視され、書き込み転送が直ちにオンになります。
-
[クラスタークラスターの変更] を選択します。
AWS CLI を使用して書き込み転送を有効にするには、--enable-global-write-forwarding
オプションを使用します。このオプションは、create-db-cluster コマンドを使用して新しいセカンダリクラスターを作成するときに機能します。modify-db-cluster コマンドを使用して、既存のセカンダリクラスターを変更する場合にも機能します。グローバルデータベースでは、書き込み転送をサポートする Aurora バージョンを使用する必要があります。これらの同じ CLI コマンドで --no-enable-global-write-forwarding
オプションを使用することで、書き込み転送をオフにすることができます。
以下の手順では、AWS CLI を使用してグローバルクラスター内のセカンダリ DB クラスターの書き込み転送を有効または無効にする方法について説明します。
既存のセカンダリ DB クラスターの書き込み転送を有効または無効にするには
-
modify-db-cluster AWS CLI コマンドを呼び出して以下の値を指定します。
-
--db-cluster-identifier
- DB クラスターの名前。 -
オンにする場合は
--enable-global-write-forwarding
、オフにする場合は--no-enable-global-write-forwarding
。
次の例では、DB クラスター
sample-secondary-db-cluster
の書き込み転送を有効にします。Linux、macOS、Unix の場合:
aws rds modify-db-cluster \ --db-cluster-identifier sample-secondary-db-cluster \ --enable-global-write-forwarding
Windows の場合:
aws rds modify-db-cluster ^ --db-cluster-identifier sample-secondary-db-cluster ^ --enable-global-write-forwarding
-
Amazon RDS API を使用して書き込み転送を有効にするには、EnableGlobalWriteForwarding
パラメータを true
に設定します。このパラメータは、CreateDBCluster オペレーションを使用して新しいセカンダリクラスターを作成するときに機能します。この操作は、ModifyDBCluster オペレーションを使用して既存のセカンダリクラスターを変更する場合にも機能します。グローバルデータベースでは、書き込み転送をサポートする Aurora バージョンを使用する必要があります。EnableGlobalWriteForwarding
パラメータを false
に設定することで、書き込み転送をオフにすることができます。
セカンダリクラスターで Aurora PostgreSQL での書き込み転送が有効になっているかどうかの確認
セカンダリクラスターからの書き込み転送を使用できるかどうかを判断するには、クラスターに属性 "GlobalWriteForwardingStatus": "enabled"
があるかどうかを確認します。
AWS Management Console では、クラスターの詳細ページの [設定] タブに 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 Global Database でセカンダリからプライマリへの書き込み転送を使用するときは、セカンダリクラスターのリーダーエンドポイントを使用します。
例
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" } ]
書き込み転送とアプリケーションおよび Aurora PostgreSQL の互換性
特定のステートメントは、書き込み転送機能を持つグローバルデータベースで使用すると、許可されないか、または古い結果を生成する可能性があります。また、ユーザー定義関数とユーザー定義プロシージャはサポートされていません。したがって、セカンダリクラスターで EnableGlobalWriteForwarding
の設定はデフォルトではオフになっています。オンにする前に、アプリケーションコードがこれらの制限の影響を受けていないことを確認してください。
書き込み転送では、次の種類の SQL ステートメントを使用できます。
-
INSERT
、DELETE
、およびUPDATE
などのデータ操作言語 (DML) ステートメント。 -
SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }
ステートメント -
PREPARE
とEXECUTE
ステートメント -
このリストにあるステートメントを含む
EXPLAIN
ステートメント
書き込み転送では、次の種類の SQL ステートメントはサポートされていません。
-
データ定義言語 (DDL) ステートメント
-
ANALYZE
-
CLUSTER
-
COPY
-
カーソル — カーソルはサポートされていないため、書き込み転送を使用する前に必ずカーソルを閉じてください。
-
GRANT
|REVOKE
|REASSIGN OWNED
|SECURITY LABEL
-
LOCK
-
SAVEPOINT
ステートメント -
SELECT INTO
-
SET CONSTRAINTS
-
TRUNCATE
-
VACUUM
Aurora PostgreSQL での書き込み転送の分離と整合性
書き込み転送を使用するセッションでは、REPEATABLE READ
および READ COMMITTED
分離レベルのみを使用できます。ただし、SERIALIZABLE
分離レベルはサポートされていません。
セカンダリクラスターの読み取り整合性の程度を制御できます。読み取り整合性レベルは、一部またはすべての変更がプライマリクラスターからレプリケートされるように、各読み取りオペレーションの前にセカンダリクラスターが実行する待機時間を決定します。読み取り整合性レベルを調整して、セッションから転送されたすべての書き込みオペレーションが、後続のクエリの前にセカンダリクラスターに表示されるようにすることができます。また、この設定を使用して、セカンダリクラスターのクエリに、常にプライマリクラスターからの最新の更新が表示されるようにすることもできます。これは、他のセッションまたは他のクラスターによって送信されたものであっても同様です。アプリケーションでこの種類の動作を指定するには、セッションレベルのパラメータ apg_write_forward.consistency_mode
の適切な値を選択します。apg_write_forward.consistency_mode
パラメータは、書き込み転送が有効になっているセカンダリクラスターでのみ有効です。
注記
apg_write_forward.consistency_mode
パラメータには、SESSION
、EVENTUAL
、GLOBAL
および OFF
の値を指定できます。デフォルトでは、値は SESSION
に設定されます。値を OFF
に設定すると、セッションでの書き込み転送が無効になります。
整合性レベルを上げると、アプリケーションは、AWS リージョン間で変更が反映されるのを待つ時間が長くなります。応答時間の短縮と、クエリを実行する前に他の場所で行われた変更が完全に使用可能であることのバランスを選択できます。
整合性モードを設定できるたびに、次のような効果が得られます。
SESSION
– 書き込み転送を使用するセカンダリ AWS リージョンのすべてのクエリに、そのセッションで行われたすべての変更の結果が表示されます。トランザクションがコミットされているかどうかにかかわらず、変更が表示されます。必要に応じて、クエリは、転送された書き込みオペレーションの結果が現在のリージョンにレプリケートされるまで待っています。他のリージョンまたは現在のリージョン内の他のセッションで実行された書き込みオペレーションの結果が更新されるのを待つことはありません。EVENTUAL
- 書き込み転送を使用するセカンダリ AWS リージョンのクエリでは、レプリケーションの遅延によりデータがわずかに古くなることがあります。同じセッションでの書き込みオペレーションの結果は、プライマリリージョンで書き込みオペレーションが実行され、現在のリージョンにレプリケートされるまで表示されません。クエリは、更新された結果が使用可能になるのを待つことはありません。したがって、ステートメントのタイミングとレプリケーションの遅延の量に応じて、古いデータや更新されたデータが取得される可能性があります。GLOBAL
— セカンダリ AWS リージョンのセッションには、そのセッションによって行われた変更が表示されます。また、プライマリ AWS リージョンと他のセカンダリ AWS リージョンの両方のコミットされた変更もすべて表示されます。各クエリは、セッション遅延の量に応じて変化する期間を待つことがあります。クエリは、クエリがスタートされた時点の、プライマリクラスターからコミットされたすべてのデータでセカンダリクラスターが最新の状態になったときに実行されます。OFF
— セッションで書き込み転送が無効です。
書き込み転送に関連するすべてのパラメータの詳細については、「Aurora PostgreSQL での書き込み転送の設定パラメータ」を参照してください。
Aurora PostgreSQL での書き込み転送を使用したマルチパートステートメントの実行
DML ステートメントは、INSERT ... SELECT
ステートメントや DELETE ... WHERE
ステートメントなど、複数の部分から構成される場合があります。この場合、ステートメント全体がプライマリクラスターに転送され、そこで実行されます。
Aurora PostgreSQL での書き込み転送の設定パラメータ
Aurora クラスターのパラメータグループには、書き込み転送機能の設定が含まれています。これらはクラスターパラメータであるため、各クラスターのすべての DB インスタンスは、これらの可変に同じ値を持ちます。これらのパラメータの詳細を次の表にまとめ、表に続いて使用上の注意を記載してください。
名前 | スコープ | タイプ | デフォルト値 | 有効値 |
---|---|---|---|---|
apg_write_forward.connect_timeout
|
セッション | 秒 | 30 | 0-2147483647 |
apg_write_forward.consistency_mode |
セッション | enum | セッション |
SESSION , EVENTUAL , GLOBAL , OFF
|
apg_write_forward.idle_in_transaction_session_timeout
|
セッション | ミリ秒 | 86400000 | 0-2147483647 |
apg_write_forward.idle_session_timeout
|
セッション | ミリ秒 | 300000 | 0-2147483647 |
apg_write_forward.max_forwarding_connections_percent
|
グローバル | 整数 | 25 | 1–100 |
apg_write_forward.max_forwarding_connections_percent
パラメータは、リーダーから転送されたクエリを処理するために使用できるデータベース接続スロットの上限です。これは、プライマリクラスター内の書き込み DB インスタンスの max_connections
設定のパーセンテージで表されます。例えば、max_connections
が 800
、apg_write_forward.max_forwarding_connections_percent
が 10
の場合、書き込みは最大 80 の同時転送セッションを許可します。これらの接続は、max_connections
設定によって管理される同じ接続プールから取得されます。この設定は、セカンダリクラスターで少なくとの 1 つの書き込み転送が有効になっている場合に、プライマリクラスターにのみ適用されます。
セカンダリクラスターでは以下の設定を使用します。
-
apg_write_forward.consistency_mode
— セカンダリクラスターの読み取り整合性の程度を制御するセッションレベルのパラメータ。有効な値はSESSION
、EVENTUAL
、GLOBAL
、またはOFF
です。デフォルトでは、値はSESSION
に設定されます。値をOFF
に設定すると、セッションでの書き込み転送が無効になります。整合性レベルの詳細については、Aurora PostgreSQL での書き込み転送の分離と整合性 を参照してください。このパラメータは、書き込み転送が有効で、Aurora Global Database 内にあるセカンダリクラスターのリーダーインスタンスでのみ関係します。 apg_write_forward.connect_timeout
— セカンダリクラスターがプライマリクラスターへの接続を確立するまでに待機する最大秒数。値が0
の場合、無期限に待機することになります。apg_write_forward.idle_in_transaction_session_timeout
– プライマリクラスターが開いているセッションのあるセカンダリクラスターから転送された接続でそれを閉じるまでアクティビティで待機するミリ秒数。トランザクションでこの期間を超えてセッションがアイドル状態のままである場合、Aurora はセッションを終了します。0
の値は、タイムアウトを無効にします。apg_write_forward.idle_session_timeout
- プライマリクラスターがセカンダリクラスターから転送された接続でアクティビティを終了するまで待機するミリ秒数。この期間を超えてセッションがアイドル状態のままである場合、Aurora はセッションを終了します。0
の値は、タイムアウトを無効にします。
Aurora PostgreSQL での書き込み転送の Amazon CloudWatch メトリクス
次の Amazon CloudWatch メトリクスは、1 つ以上のセカンダリクラスターで書き込み転送を使用する場合、プライマリクラスターに適用されます。これらのメトリクスはすべて、プライマリクラスターのライター DB インスタンスで測定されます。
CloudWatch メトリクス | 単位と説明 |
---|---|
|
1 秒あたりのカウント数。この書き込み DB インスタンスによって 1 秒間に処理される、転送された DML ステートメントの数。 |
|
カウント。転送されたクエリを処理しているこのライター DB インスタンスで開いているセッションの数。 |
|
カウント。このライター DB インスタンスで転送されたセッションの合計数。 |
次の CloudWatch メトリクスは、各セカンダリクラスターに適用されます。これらのメトリクスは、書き込み転送が有効になっているセカンダリクラスターのリーダー DB インスタンスで測定されます。
CloudWatch メトリクス | 単位と説明 |
---|---|
|
1 秒あたりのカウント数。このレプリカが 1 秒あたりに転送したセッションのコミット数。 |
|
ミリ秒。レプリカ上で転送された DML の平均応答時間 (ミリ秒)。 |
|
1 秒あたりのカウント数。このレプリカで 1 秒あたりに処理された転送 DML ステートメントの数。 |
|
カウント。最大接続または最大書き込み転送接続の制限に達したためにプライマリクラスターが拒否したセッションの数。 |
|
カウント。リーダー DB インスタンスで書き込み転送を使用しているセッションの数。 |
|
ミリ秒。レプリカがプライマリクラスターの LSN と一致するまで待機する平均待機時間 (ミリ秒単位)。リーダー DB インスタンスが待機する程度は、apg_write_forward.consistency_mode 設定によって異なります。この設定についての情報は、「Aurora PostgreSQL での書き込み転送の設定パラメータ」を参照してください。 |
Aurora PostgreSQL での書き込み転送のイベントを待機する
Aurora PostgreSQL で書き込み転送を使用すると、Amazon Aurora は次の待機イベントを生成します。
トピック
IPC:AuroraWriteForwardConnect
IPC:AuroraWriteForwardConnect
イベントは、セカンダリ DB クラスターのバックエンドプロセスが、プライマリ DB クラスターのライターノードへの接続が開かれるのを待っているときに発生します。
待機時間が増加する原因の可能性
このイベントは、セカンダリージョンのリーダーノードからプライマリ DB クラスターのライターノードへの接続試行回数が増えるにつれて増加します。
アクション
セカンダリノードからプライマリリージョンのライターノードへの同時接続数を減らします。
IPC:AuroraWriteForwardConsistencyPoint
IPC:AuroraWriteForwardConsistencyPoint
イベントは、転送された書き込みオペレーションの結果が現在のリージョンにレプリケートされるまでセカンダリ DB クラスターのノードからのクエリが待機する時間を記述します。このイベントは、セッションレベルのパラメータ apg_write_forward.consistency_mode
が次のいずれかに設定されている場合にのみ生成されます。
SESSION
— セカンダリノードのクエリは、そのセッションで行われたすべての変更の結果が終わるまで待機します。GLOBAL
— セカンダリノード上のクエリは、そのセッションで行われた変更の結果に加えて、グローバルクラスター内のプライマリリージョンと他のセカンダリリージョンの両方でコミットされたすべての変更の結果を待ちます。
apg_write_forward.consistency_mode
パラメータの設定の詳細については、「Aurora PostgreSQL での書き込み転送の設定パラメータ」をご参照ください。
待機時間が増加する原因の可能性
待機時間が長くなる一般的な原因には以下のものがあります。
Amazon CloudWatch
ReplicaLag
メトリクスで測定すると、レプリカの遅延が増加しました。このメトリクスの詳細については、「Aurora PostgreSQL レプリケーションのモニタリング」を参照してください。プライマリリージョンのライターノードまたはセカンダリノードの負荷が増加した。
アクション
アプリケーションの要件に応じて、整合性モードを変更します。
IPC:AuroraWriteForwardExecute
IPC:AuroraWriteForwardExecute
イベントは、セカンダリ DB クラスターのバックエンドプロセスが、転送されたクエリを完了し、プライマリ DB クラスターのライターノードからの結果を取得するのを待っているときに発生します。
待機時間が増加する原因の可能性
待機時間の増加の一般的な原因としては、以下が挙げられます。
プライマリリージョンのライターノードから多数の行をフェッチしている。
セカンダリノードとプライマリリージョンのライターノード間のネットワークレイテンシーが長くなると、セカンダリノードがライターノードからデータを受信するまでにかかる時間が長くなります。
セカンダリノードの負荷が増加すると、セカンダリノードからプライマリリージョンのライターノードへのクエリリクエストの送信が遅れる可能性があります。
プライマリリージョンのライターノードの負荷が増加すると、ライターノードからセカンダリノードへのデータの送信が遅れる可能性があります。
アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
必要なデータのみを取得するようにクエリを最適化します。
データ操作言語 (DML) オペレーションを最適化し、必要なデータのみを変更します。
セカンダリノードまたはプライマリリージョンのライターノードが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅の大きいインスタンスタイプに変更することを検討してください。
IPC:AuroraWriteForwardGetGlobalConsistencyPoint
IPC:AuroraWriteForwardGetGlobalConsistencyPoint
イベントは、GLOBAL 整合性モードを使用しているセカンダリ DB クラスター上のバックエンドプロセスが、クエリを実行する前に、ライターノードからグローバル整合性ポイントを取得するのを待っているときに発生します。
待機時間が増加する原因の可能性
待機時間の増加の一般的な原因としては、以下が挙げられます。
セカンダリノードとプライマリリージョンのライターノード間のネットワークレイテンシーが長くなると、セカンダリノードがライターノードからデータを受信するまでにかかる時間が長くなります。
セカンダリノードの負荷が増加すると、セカンダリノードからプライマリリージョンのライターノードへのクエリリクエストの送信が遅れる可能性があります。
プライマリリージョンのライターノードの負荷が増加すると、ライターノードからセカンダリノードへのデータの送信が遅れる可能性があります。
アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
アプリケーションの要件に応じて、整合性モードを変更します。
セカンダリノードまたはプライマリリージョンのライターノードが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅の大きいインスタンスタイプに変更することを検討してください。
IPC:AuroraWriteForwardXactAbort
IPC:AuroraWriteForwardXactAbort
イベントは、セカンダリ DB クラスターのバックエンドプロセスがリモートクリーンアップクエリの結果を待っているときに発生します。クリーンアップクエリは、書き込み転送されたトランザクションが中止された後にプロセスを適切な状態に戻すために発行されます。Amazon Aurora は、エラーが見つかったか、ユーザーが明示的な ABORT
コマンドを発行したか、実行中のクエリをキャンセルしたためにそれらを実行します。
待機時間が増加する原因の可能性
待機時間の増加の一般的な原因としては、以下が挙げられます。
セカンダリノードとプライマリリージョンのライターノード間のネットワークレイテンシーが長くなると、セカンダリノードがライターノードからデータを受信するまでにかかる時間が長くなります。
セカンダリノードの負荷が増加すると、セカンダリノードからプライマリリージョンのライターノードへのクリーンナップクエリリクエストの送信が遅れる可能性があります。
プライマリリージョンのライターノードの負荷が増加すると、ライターノードからセカンダリノードへのデータの送信が遅れる可能性があります。
アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
中断されたトランザクションの原因を調査します。
セカンダリノードまたはプライマリリージョンのライターノードが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅の大きいインスタンスタイプに変更することを検討してください。
IPC:AuroraWriteForwardXactCommit
IPC:AuroraWriteForwardXactCommit
イベントは、セカンダリ DB クラスターのバックエンドプロセスが、転送されたコミットトランザクションコマンドの結果を待っているときに発生します。
待機時間が増加する原因の可能性
待機時間の増加の一般的な原因としては、以下が挙げられます。
セカンダリノードとプライマリリージョンのライターノード間のネットワークレイテンシーが長くなると、セカンダリノードがライターノードからデータを受信するまでにかかる時間が長くなります。
セカンダリノードの負荷が増加すると、セカンダリノードからプライマリリージョンのライターノードへのクエリリクエストの送信が遅れる可能性があります。
プライマリリージョンのライターノードの負荷が増加すると、ライターノードからセカンダリノードへのデータの送信が遅れる可能性があります。
アクション
セカンダリノードまたはプライマリリージョンのライターノードが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅の大きいインスタンスタイプに変更することを検討してください。
IPC:AuroraWriteForwardXactStart
IPC:AuroraWriteForwardXactStart
イベントは、セカンダリ DB クラスターのバックエンドプロセスが、転送された開始トランザクションコマンドの結果を待っているときに発生します。
待機時間が増加する原因の可能性
待機時間の増加の一般的な原因としては、以下が挙げられます。
セカンダリノードとプライマリリージョンのライターノード間のネットワークレイテンシーが長くなると、セカンダリノードがライターノードからデータを受信するまでにかかる時間が長くなります。
セカンダリノードの負荷が増加すると、セカンダリノードからプライマリリージョンのライターノードへのクエリリクエストの送信が遅れる可能性があります。
プライマリリージョンのライターノードの負荷が増加すると、ライターノードからセカンダリノードへのデータの送信が遅れる可能性があります。
アクション
セカンダリノードまたはプライマリリージョンのライターノードが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅の大きいインスタンスタイプに変更することを検討してください。