# Aurora PostgreSQL のローカル書き込み転送 ローカル (クラスター内) 書き込み転送により、アプリケーションは Aurora レプリカで直接、読み取り/書き込みトランザクションを発行できます。次に、書き込みコマンドがライター DB インスタンスに転送されてコミットされます。ローカル書き込み転送は、アプリケーションで時折書き込みが発生し、*書き込み後の読み取りの一貫性* (トランザクション内の最新の書き込みを読み取る機能) を必要とする場合に使用できます。 書き込み転送を使用しない場合、アプリケーションは、すべての読み取りトラフィックと書き込みトラフィックを完全に分割して 2 セットのデータベース接続を維持し、トラフィックを適切なエンドポイントに送信する必要があります。リードレプリカは、ライターインスタンスから非同期で更新を受け取ります。さらに、レプリケーションの遅延はリードレプリカによって異なる可能性があるため、すべてのレプリカでグローバルな読み取り一貫性を実現することは困難です。書き込み後の読み取りの一貫性を必要とする読み取りは、ライターデータベースインスタンスで処理する必要があります。または、複雑なカスタムアプリケーションロジックを開発して、複数のリードレプリカを活用してスケーラビリティを高めるとともに一貫性を確保する必要があります。 書き込み転送を使用すると、これらのトランザクションを分割したり、送信先をライターインスタンスに限定したりする必要がなくなります。また、*書き込み後の読み取りの一貫性*を実現するために、複雑なアプリケーションロジックを開発する必要もありません。 ローカル書き込み転送は、Aurora PostgreSQL が利用可能なすべてのリージョンで使用できます。以下のバージョンの Aurora PostgreSQL でサポートされています。 + 16.4 以降の 16 バージョン + 15.8 以降の 15 バージョン + 14.13 以降の 14 バージョン ローカル書き込み転送は、リージョン内レプリカからの書き込みを転送するために使用します。グローバルレプリカからの書き込みを転送するには、「[Amazon Aurora Global Database の書き込み転送を使用する](aurora-global-database-write-forwarding.md)」を参照してください。 **Topics** + [Aurora PostgreSQL でのローカル書き込み転送の制限と考慮事項](aurora-postgresql-write-forwarding-limitations.md) + [ローカル書き込み転送用の Aurora PostgreSQL の設定](aurora-postgresql-write-forwarding-configuring.md) + [Aurora PostgreSQL のローカル書き込み転送の使用](aurora-postgresql-write-forwarding-understanding.md) + [Aurora PostgreSQL でのローカル書き込み転送のモニタリング](aurora-postgresql-write-forwarding-monitoring.md) # Aurora PostgreSQL でのローカル書き込み転送の制限と考慮事項 Aurora PostgreSQL でのローカル転送には、現在、以下の制限が適用されます。 + ローカル書き込み転送は RDS Proxy ではサポートされていません。 + 書き込み転送機能を持つ Aurora PostgreSQL では、特定のステートメントが許可されないか、古い結果を生成する可能性があります。また、ユーザー定義関数とユーザー定義プロシージャはサポートされていません。したがって、DB クラスターでは `EnableLocalWriteForwarding` 設定がデフォルトではオフになっています。オンにする前に、アプリケーションコードがこれらの制限の影響を受けていないことを確認してください。 + 書き込み転送では、次の種類の SQL ステートメントはサポートされていません。 **注記** これらのステートメントは、アプリケーションで暗黙的に使用することも、PostgreSQL プロトコルで推測することもできます。例えば、PL/SQL 例外処理では、サポートされていないステートメントである SAVEPOINT が使用される場合があります。 + `ANALYZE` + `CLUSTER` + `COPY` + カーソル — カーソルはサポートされていないため、ローカル書き込み転送を使用する前に必ずカーソルを閉じてください。 + データ定義言語 (DDL) ステートメント + `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL` + `LISTEN / NOTIFY` + `LOCK` + `SAVEPOINT` + `SELECT INTO` + `SET CONSTRAINTS` + シーケンスの更新: `nextval()`、`setval()` + `TRUNCATE` + 2 相コミットコマンド: `PREPARE TRANSACTION`、`COMMIT PREPARED`、`ROLLBACK PREPARED` + ユーザー定義関数とユーザー定義プロシージャ。 + `VACUUM` 書き込み転送では、以下の SQL ステートメントを使用することを検討できます。 + DML ステートメントは、`INSERT ... SELECT` ステートメントや `DELETE ... WHERE` ステートメントなど、複数の部分から構成される場合があります。この場合、ステートメント全体がライター DB インスタンスに転送され、そこで実行されます。 + `INSERT`、`DELETE`、および `UPDATE` などのデータ操作言語 (DML) ステートメント。 + このリストにあるステートメントを含む `EXPLAIN` ステートメント + `PREPARE` と `EXECUTE` ステートメント。 + `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }` ステートメント。 # ローカル書き込み転送用の Aurora PostgreSQL の設定 以下のセクションを使用すると、Amazon Aurora PostgreSQL DB クラスターのローカル書き込み転送を有効にし、整合性レベルを設定して、書き込み転送でトランザクションを管理できるようになります。 ## ローカル書き込み転送の有効化 デフォルトでは、Aurora PostgreSQL DB クラスターのローカル書き込み転送は有効になっていません。ローカル書き込み転送は、インスタンスレベルではなくクラスターレベルで有効にします。 ### コンソール DB クラスターを作成または変更するときに、AWS マネジメントコンソール を使用して、**[リードレプリカの書き込み転送]** の **[ローカル書き込み転送を有効にする]** チェックボックスを選択します。 ### AWS CLI AWS CLI でローカル書き込み転送を有効にするには、`--enable-local-write-forwarding` オプションを使用します。このオプションは、`create-db-cluster` コマンドを使用して新しい DB クラスターを作成するときに機能します。`modify-db-cluster` コマンドを使用して、既存の DB クラスターを変更する場合にも機能します。これらの同じ CLI コマンドで `--no-enable-local-write-forwarding` オプションを使用することで、ローカル書き込み転送を無効にすることができます。 次の例では、ローカル書き込み転送を有効にして Aurora PostgreSQL DB クラスターを作成します。 ``` aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \ --enable-local-write-forwarding \ --engine aurora-postgresql \ --engine-version 16.4 \ --master-username myuser \ --master-user-password mypassword \ --backup-retention 1 ``` 次に、書き込み転送を使用できるように、ライター DB インスタンスとリーダー DB インスタンスを作成します。詳細については、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。 ### RDS API Amazon RDS API を使用してローカル書き込み転送を有効にするには、`EnableLocalWriteForwarding` パラメータを `true` に設定します。このパラメータは、`CreateDBCluster` オペレーションを使用して新しい DB クラスターを作成するときに機能します。この操作は、`ModifyDBCluster` オペレーションを使用して既存の DB クラスターを変更する場合にも機能します。`EnableLocalWriteForwarding` パラメータを `false` に設定することで、ローカル書き込み転送を無効にすることができます。 ### データベースセッションのローカル書き込み転送を有効にする `apg_write_forward.consistency_mode` パラメータは、書き込み転送を有効にする DB パラメータと DB クラスターパラメータです。読み取り整合性レベルには、`SESSION`、`EVENTUAL`、`GLOBAL`、または `OFF` を指定できます。整合性レベルの詳細については、[Aurora PostgreSQL でのローカル書き込み転送の整合性と分離](#aurora-postgresql-write-forwarding-isolation) を参照してください。 このパラメータには、次の規則が適用されます。 + デフォルト値は `SESSION` です。 + ローカル書き込み転送は、`apg_write_forward.consistency_mode` を `EVENTUAL`、`SESSION`、または `GLOBAL` に設定した場合にのみ使用できます。このパラメータは、ローカル書き込み転送が有効になっている DB クラスターのリーダーインスタンスにのみ関係します。 + 値を `OFF` に設定すると、セッションでのローカル書き込み転送が無効になります。 ## Aurora PostgreSQL でのローカル書き込み転送の整合性と分離 リードレプリカの読み取り整合性の度合いを制御できます。読み取り整合性レベルを調整して、セッションから転送したすべての書き込みオペレーションを、後続のクエリの前に、リードレプリカに表示できます。また、この設定を使用して、リードレプリカのクエリで常にライター DB インスタンスの最新の更新を参照することもできます。これは、他のセッションまたは他のクラスターによって送信されたものであっても同様です。アプリケーションでこの種類の動作を指定するには、セッションレベルのパラメータ `apg_write_forward.consistency_mode` の適切な値を選択します。`apg_write_forward.consistency_mode` パラメータは、ローカル書き込み転送が有効になっているリードレプリカにのみ影響します。 **注記** `apg_write_forward.consistency_mode` パラメータには、`SESSION`、`EVENTUAL`、`GLOBAL` および `OFF` の値を指定できます。デフォルトでは、値は `SESSION` に設定されます。値を `OFF` に設定すると、書き込み転送が無効になります。 整合性レベルを上げると、リードレプリカに変更が反映されるまでアプリケーションで待つ時間が長くなります。レイテンシーを短縮することと、他の場所での変更が完全に利用可能になってからクエリを実行することのバランスを選択できます。 利用可能な整合性モードの設定ごとに、次のような効果があります。 + `SESSION` – ローカル書き込み転送を使用するリードレプリカのセッションでは、そのセッションで行われたすべての変更の結果を表示できます。トランザクションがコミットされているかどうかにかかわらず、変更が表示されます。必要に応じて、クエリは、転送された書き込みオペレーションの結果が現在のリーダー DB インスタンスにレプリケートされるまで待ちます。他のセッションで実行された書き込みオペレーションの結果が現在の DB クラスター内で更新されるのを待つことはありません。 + `EVENTUAL` – ローカル書き込み転送を使用するセッションでは、レプリケーションの遅延により、わずかに古いデータが表示されることがあります。同じセッションでの書き込みオペレーションの結果は、ライター DB インスタンスで書き込みオペレーションを実行してリードレプリカにレプリケートするまで表示されません。クエリは、更新された結果が使用可能になるのを待つことはありません。したがって、ステートメントのタイミングとレプリケーションの遅延の量に応じて、古いデータや更新されたデータが取得される可能性があります。 + `GLOBAL` – リードレプリカのセッションでは、そのセッションで行った変更が表示されます。また、ライター DB インスタンスと他のリードレプリカの両方からコミットされたすべての変更も表示されます。各クエリは、セッション遅延の量に応じて待機時間が異なる場合があります。クエリを開始した時点で、ライター DB インスタンスからコミットされたすべてのデータでリードレプリカが最新の状態であると、クエリは続行します。 **注記** グローバル整合性モードは、セッション内で実行するクエリのレイテンシーに影響します。セッションが書き込みクエリを送信していない場合でも、待機が行われます。 + `OFF` — ローカル書き込み転送は無効です。 書き込み転送を使用するセッションでは、`REPEATABLE READ` および `READ COMMITTED` 分離レベルのみを使用できます。ただし、`SERIALIZABLE` 分離レベルはサポートされていません。 書き込み転送に関連するすべてのパラメータの詳細については、「[書き込み転送のデフォルトのパラメータ設定](aurora-postgresql-write-forwarding-understanding.md#aurora-postgresql-write-forwarding-params)」を参照してください。 ## 書き込み転送によるトランザクションアクセスモード トランザクションアクセスモードを読み取り専用に設定している場合、ローカル書き込み転送は使用されません。ローカル書き込み転送が有効になっている DB クラスターおよびセッションに接続している場合にのみ、書き込みを読み取るようにアクセスモードを設定できます。 トランザクションアクセスモードの詳細については、「[SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html)」を参照してください。 # Aurora PostgreSQL のローカル書き込み転送の使用 以下のセクションを使用して、データベースクラスターでローカル書き込み転送が有効になっているかどうかと、互換性に関する考慮事項、設定可能なパラメータと認証設定について確認できます。この情報は、Aurora PostgreSQL でローカル書き込み転送機能を効果的に活用するための詳細を提供します。 **注記** ローカル書き込み転送を使用しているクラスター内のライターインスタンスが再起動されると、ローカル書き込み転送を使用しているリーダーインスタンス上のアクティブで転送されたトランザクションとクエリは自動的に閉じられます。ライターインスタンスが再び使用可能になったら、これらのトランザクションを再試行できます。 ## DB クラスターでローカル書き込み転送が有効になっているかどうかの確認 DB クラスターでローカル書き込み転送を使用できることを確かめるには、クラスターの属性 `LocalWriteForwardingStatus` が `enabled` に設定されていることを確認します。 AWS マネジメントコンソール のクラスターの詳細ページの **[設定]** タブで、**[ローカルリードレプリカの書き込み転送]** のステータスが **[有効]** と表示されます。 すべてのクラスターについてローカル書き込み転送設定のステータスを確認するには、次の AWS CLI コマンドを実行します。 **Example** ``` aws rds describe-db-clusters \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}' [ { "LocalWriteForwardingStatus": "enabled", "DBClusterIdentifier": "write-forwarding-test-cluster-1" }, { "LocalWriteForwardingStatus": "disabled", "DBClusterIdentifier": "write-forwarding-test-cluster-2" }, { "LocalWriteForwardingStatus": "requested", "DBClusterIdentifier": "test-global-cluster-2" }, { "LocalWriteForwardingStatus": "null", "DBClusterIdentifier": "aurora-postgresql-v2-cluster" } ] ``` DB クラスターは、`LocalWriteForwardingStatus` として以下の値を持ちます。 + `disabled` — ローカル書き込み転送は無効です。 + `disabling` — ローカル書き込み転送は無効化中です。 + `enabled` — ローカル書き込み転送は有効です。 + `enabling` — ローカル書き込み転送は有効化中です。 + `null` — この DB クラスターではローカル書き込み転送を使用できません。 + `requested` — ローカル書き込み転送がリクエストされていますが、まだアクティブではありません。 ## 書き込み転送のデフォルトのパラメータ設定 Aurora クラスターのパラメータグループには、ローカル書き込み転送機能の設定が含まれています。これらはクラスターパラメータであるため、各クラスターのすべての DB インスタンスは、これらの可変に同じ値を持ちます。これらのパラメータの詳細を次の表にまとめ、表に続いて使用上の注意を記載してください。 | パラメータ | スコープ | タイプ | デフォルト値 | 有効値 | | --- | --- | --- | --- | --- | | apg\$1write\$1forward.connect\$1timeout | セッション | 秒 | 30 | 0-2147483647 | | apg\$1write\$1forward.consistency\$1mode | セッション | enum | セッション | SESSION、EVENTUAL、GLOBAL、および OFF | | apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | セッション | ミリ秒 | 86400000 | 0-2147483647 | | apg\$1write\$1forward.idle\$1session\$1timeout | セッション | ミリ秒 | 300000 | 0-2147483647 | | apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | グローバル | int | 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` 設定によって管理される同じ接続プールから取得されます。この設定は、クラスターでローカル書き込み転送が有効になっているライター DB インスタンスにのみ適用されます。 ローカル書き込み転送リクエストを制御するには、以下の設定を使用します。 + `apg_write_forward.consistency_mode` — リードレプリカの読み取り整合性の度合いを制御するセッションレベルのパラメータ。有効な値は `SESSION`、`EVENTUAL`、`GLOBAL`、または `OFF` です。デフォルトでは、値は `SESSION` に設定されます。値を `OFF` に設定すると、セッションでのローカル書き込み転送が無効になります。整合性レベルの詳細については、[Aurora PostgreSQL でのローカル書き込み転送の整合性と分離](aurora-postgresql-write-forwarding-configuring.md#aurora-postgresql-write-forwarding-isolation) を参照してください。このパラメータは、ローカル書き込み転送が有効になっているリーダーインスタンスにのみ関係します。 + `apg_write_forward.connect_timeout` – リードレプリカがライター DB インスタンスへの接続を確立するために待機を始めてから止めるまでの最大秒数。値が `0` の場合、無期限に待機することになります。 + `apg_write_forward.idle_in_transaction_session_timeout` — リーダー DB インスタンスが、オープントランザクションを持つリードレプリカから転送されるアクティビティを接続で待機し始めてから、接続を閉じるまでのミリ秒数。トランザクションでこの期間を超えてセッションがアイドル状態のままである場合、Aurora はセッションを終了します。`0` の値は、タイムアウトを無効にします。 + `apg_write_forward.idle_session_timeout` — ライター DB インスタンスが、リーダーインスタンスから転送されるアクティビティを接続で待機し始めてから、接続を閉じるまでのミリ秒数。この期間を超えてセッションがアイドル状態のままである場合、Aurora はセッションを終了します。`0` の値は、タイムアウトを無効にします。 ## rdswriteforwarduser `rdswriteforwarduser` は、リードレプリカとライター DB インスタンスの間の接続を確立するために使用するユーザーです。 **注記** `rdswriteforwarduser` は PUBLIC ロールを介して CONNECT 権限をカスタマーデータベースに継承します。PUBLIC ロールの権限が取り消された場合は、書き込みを転送する必要があるデータベースに接続権限を付与 (GRANT CONNECT) する必要があります。 # Aurora PostgreSQL でのローカル書き込み転送のモニタリング 以下のセクションを使用すると、関連する CloudWatch メトリクスや待機イベントなど、Aurora PostgreSQL クラスターのローカル書き込み転送をモニタリングして、パフォーマンスを追跡し、潜在的な問題を特定できます。 ## 書き込み転送のための Amazon CloudWatch メトリクスと Aurora PostgreSQL ステータス変数 1 つ以上のリードレプリカで書き込み転送を使用する場合、以下の Amazon CloudWatch メトリクスがライター DB インスタンスに適用されます。 | CloudWatch メトリクス | 単位と説明 | | --- | --- | | `AuroraLocalForwardingWriterDMLThroughput` | 1 秒あたりのカウント数。この書き込み DB インスタンスによって 1 秒間に処理される、転送された DML ステートメントの数。 | | `AuroraLocalForwardingWriterOpenSessions` | カウント。転送されたクエリを処理しているこのライター DB インスタンスで開いているセッションの数。 | | `AuroraLocalForwardingWriterTotalSessions` | カウント。このライター DB インスタンスで転送されたセッションの合計数。 | 以下の CloudWatch メトリクスは、各リードレプリカに適用されます。これらのメトリクスは、ローカル書き込み転送が有効になっている DB クラスター内の各リーダー DB インスタンスで測定されます。 | CloudWatch メトリクス | 単位と説明 | | --- | --- | | `AuroraForwardingReplicaCommitThroughput` | 1 秒あたりのカウント数。このレプリカが 1 秒あたりに転送したセッションのコミット数。 | | `AuroraForwardingReplicaDMLLatency` | ミリ秒。レプリカ上で転送された DML の平均応答時間 (ミリ秒)。 | | `AuroraForwardingReplicaDMLThroughput` | 1 秒あたりのカウント数。このレプリカで 1 秒あたりに処理された転送 DML ステートメントの数。 | | `AuroraForwardingReplicaErrorSessionsLimit` | カウント。最大接続数または最大書き込み転送接続数の制限に達したためにライター DB インスタンスが拒否したセッションの数。 | | `AuroraForwardingReplicaOpenSessions` | カウント。レプリカインスタンスでローカル書き込み転送を使用しているセッションの数。 | | `AuroraForwardingReplicaReadWaitLatency` | ミリ秒。レプリカがライター DB インスタンスの LSN と一致するまで待機する平均待機時間 (ミリ秒単位)。リーダー DB インスタンスが待機する程度は、apg\$1write\$1forward.consistency\$1mode 設定によって異なります。この設定についての情報は、「[Aurora PostgreSQL での書き込み転送の設定パラメータ](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg)」を参照してください。 | ## Aurora PostgreSQL でのローカル書き込み転送の待機イベント Aurora PostgreSQL で書き込み転送を使用すると、Amazon Aurora は次の待機イベントを生成します。 **Topics** + [IPC:AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect) + [IPC:AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint) + [IPC:AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute) + [IPC:AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint) + [IPC:AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort) + [IPC:AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit) + [IPC:AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart) ### IPC:AuroraWriteForwardConnect `IPC:AuroraWriteForwardConnect` イベントは、リードレプリカのバックエンドプロセスがライター DB インスタンスへの接続が開かれるまで待っているときに発生します。 **待機時間が増加する原因の可能性** このイベントは、リードレプリカからライターノードへの接続試行回数が増えるに従って増加します。 **アクション** リードレプリカからライターノードへの同時接続数を減らします。 ### IPC:AuroraWriteForwardConsistencyPoint `IPC:AuroraWriteForwardConsistencyPoint` イベントは、リードレプリカのノードからのクエリが、転送された書き込みオペレーションの結果が現在のリージョンにレプリケートされるまで待機する時間を示します。このイベントは、セッションレベルのパラメータ `apg_write_forward.consistency_mode` が次のいずれかに設定されている場合にのみ生成されます。 + `SESSION` — リードレプリカに対するクエリは、そのセッションで行われたすべての変更の結果を待機します。 + `GLOBAL` – リードレプリカに対するクエリは、そのセッションで行われた変更の結果に加えて、ライター DB インスタンスとリードレプリカの両方からコミットされたすべての変更を待機します。 `apg_write_forward.consistency_mode` パラメータの設定の詳細については、「[Aurora PostgreSQL での書き込み転送の設定パラメータ](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg)」をご参照ください。 **待機時間が増加する原因の可能性** 待機時間が長くなる一般的な原因には以下のものがあります。 + レプリカの遅延の増加 (Amazon CloudWatch `ReplicaLag` メトリクスで測定)。このメトリクスの詳細については、「[Aurora PostgreSQL レプリケーションのモニタリング](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring)」を参照してください。 + ライター DB インスタンスまたはリードレプリカでの負荷の増加。 **アクション** アプリケーションの要件に応じて、整合性モードを変更します。 ### IPC:AuroraWriteForwardExecute `IPC:AuroraWriteForwardExecute` イベントは、リードレプリカのバックエンドプロセスが、クエリの転送が完了して DB クラスターのライターノードから結果を取得するまで待っているときに発生します。 **待機時間が増加する原因の可能性** 待機時間の増加の一般的な原因としては、以下が挙げられます。 + ライターノードから多数の行を取得しています。 + ライターノードとリードレプリカの間のネットワークレイテンシーが長くなると、リードレプリカがライターノードからデータを受信するまでにかかる時間が長くなります。 + リードレプリカの負荷が増加すると、リードレプリカからライターノードへのクエリリクエストの送信が遅れる可能性があります。 + ライターノードの負荷が増加すると、ライターノードからリードレプリカへのデータの送信が遅れる可能性があります。 **アクション** 待機イベントの原因に応じたさまざまなアクションをお勧めします。 + 必要なデータのみを取得するようにクエリを最適化します。 + データ操作言語 (DML) オペレーションを最適化し、必要なデータのみを変更します。 + リードレプリカまたはライターノードが CPU やネットワーク帯域幅によって制約されている場合は、CPU キャパシティやネットワーク帯域幅のより大きいインスタンスタイプに変更することを検討してください。 ### IPC:AuroraWriteForwardGetGlobalConsistencyPoint `IPC:AuroraWriteForwardGetGlobalConsistencyPoint` イベントは、GLOBAL 整合性モードを使用しているリードレプリカのバックエンドプロセスが、クエリを実行する前に、ライターノードからグローバル整合性ポイントを取得するのを待っているときに発生します。 **待機時間が増加する原因の可能性** 待機時間の増加の一般的な原因としては、以下が挙げられます。 + リードレプリカとライターノードの間のネットワークレイテンシーが長くなると、リードレプリカがライターノードからデータを受信するまでにかかる時間が長くなります。 + リードレプリカの負荷が増加すると、リードレプリカからライターノードへのクエリリクエストの送信が遅れる可能性があります。 + ライターノードの負荷が増加すると、ライターノードからリードレプリカへのデータの送信が遅れる可能性があります。 **アクション** 待機イベントの原因に応じたさまざまなアクションをお勧めします。 + アプリケーションの要件に応じて、整合性モードを変更します。 + リードレプリカまたはライターノードが CPU やネットワーク帯域幅によって制約されている場合は、CPU キャパシティやネットワーク帯域幅のより大きいインスタンスタイプに変更することを検討してください。 ### IPC:AuroraWriteForwardXactAbort `IPC:AuroraWriteForwardXactAbort` イベントは、リードレプリカのバックエンドプロセスがリモートクリーンアップクエリの結果を待っているときに発生します。クリーンアップクエリは、書き込み転送されたトランザクションが中止された後にプロセスを適切な状態に戻すために発行されます。Amazon Aurora は、エラーが見つかったか、ユーザーが明示的な `ABORT` コマンドを発行したか、実行中のクエリをキャンセルしたためにそれらを実行します。 **待機時間が増加する原因の可能性** 待機時間の増加の一般的な原因としては、以下が挙げられます。 + リードレプリカとライターノードの間のネットワークレイテンシーが長くなると、リードレプリカがライターノードからデータを受信するまでにかかる時間が長くなります。 + リードレプリカの負荷が増加すると、リードレプリカからライターノードへのクリーンアップクエリリクエストの送信が遅延する可能性があります。 + ライターノードの負荷が増加すると、ライターノードからリードレプリカへのデータの送信が遅れる可能性があります。 **アクション** 待機イベントの原因に応じたさまざまなアクションをお勧めします。 + 中断されたトランザクションの原因を調査します。 + リードレプリカまたはライター DB インスタンスが CPU またはネットワーク帯域幅によって制約されている場合は、CPU キャパシティまたはネットワーク帯域幅のより大きいインスタンスタイプに変更することを検討してください。 ### IPC:AuroraWriteForwardXactCommit `IPC:AuroraWriteForwardXactCommit` イベントは、リードレプリカのバックエンドプロセスが、トランザクションのコミットコマンドの転送結果を待っているときに発生します。 **待機時間が増加する原因の可能性** 待機時間の増加の一般的な原因としては、以下が挙げられます。 + リードレプリカとライターノードの間のネットワークレイテンシーが長くなると、リードレプリカがライターノードからデータを受信するまでにかかる時間が長くなります。 + リードレプリカの負荷が増加すると、リードレプリカからライターノードへのクエリリクエストの送信が遅れる可能性があります。 + ライターノードの負荷が増加すると、ライターノードからリードレプリカへのデータの送信が遅れる可能性があります。 **アクション** リードレプリカまたはライターノードが CPU やネットワーク帯域幅によって制約されている場合は、CPU キャパシティやネットワーク帯域幅のより大きいインスタンスタイプに変更することを検討してください。 ### IPC:AuroraWriteForwardXactStart `IPC:AuroraWriteForwardXactStart` イベントは、リードレプリカのバックエンドプロセスが、トランザクションの開始コマンドの転送結果を待っているときに発生します。 **待機時間が増加する原因の可能性** 待機時間の増加の一般的な原因としては、以下が挙げられます。 + リードレプリカとライターノードの間のネットワークレイテンシーが長くなると、リードレプリカがライターノードからデータを受信するまでにかかる時間が長くなります。 + リードレプリカの負荷が増加すると、リードレプリカからライターノードへのクエリリクエストの送信が遅れる可能性があります。 + ライターノードの負荷が増加すると、ライターノードからリードレプリカへのデータの送信が遅れる可能性があります。 **アクション** リードレプリカまたはライターノードが CPU やネットワーク帯域幅によって制約されている場合は、CPU キャパシティやネットワーク帯域幅のより大きいインスタンスタイプに変更することを検討してください。