# Aurora PostgreSQL Limitless Database のモニタリング
Amazon CloudWatch、拡張モニタリング、Performance Insights を使用して、Aurora PostgreSQL Limitless Database をモニタリングできます。Aurora PostgreSQL Limitless Database には、モニタリングと診断に使用できる新しい統計関数とビュー、待機イベントも追加されています。
**Topics**
+ [Amazon CloudWatch による Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.cw.md)
+ [CloudWatch Database Insights による Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.cwdbi.md)
+ [Amazon CloudWatch Logs による Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.cwl.md)
+ [拡張モニタリングによる Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.em.md)
+ [Performance Insights による Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.pi.md)
+ [Amazon GuardDuty RDS Protection による Aurora PostgreSQL Limitless Database のモニタリング](limitless-monitoring.gd.md)
+ [Aurora PostgreSQL Limitless Database の関数とビュー](limitless-monitoring-fns-views.md)
+ [Aurora PostgreSQL Limitless Database の待機イベント](limitless-monitoring-waits.md)
+ [関数を使用した効率向上の構築](limitless-performance-functions.md)
# Amazon CloudWatch による Aurora PostgreSQL Limitless Database のモニタリング
Aurora PostgreSQL Limitless Database の CloudWatch メトリクスは、次のディメンションで報告されます。
+ [DBShardGroup](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier)
CloudWatch のメトリクスの詳細については、「[Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。
## DBShardGroup メトリクス
CloudWatch コンソールで Aurora PostgreSQL Limitless Database の `DBShardGroup` メトリクスを表示するには、**[RDS]**、**[DBShardGroup]** の順に選択します。
次の CloudWatch メトリクスを追跡できます。
+ `DBShardGroupACUUtilization` – `DBShardGroupCapacity` を `DBShardGroupMaxACU` で割った値から計算された Aurora 容量ユニット (ACU) の使用率。
+ `DBShardGroupCapacity` – DB シャードグループのライターインスタンスによって消費された ACU の数。
+ `DBShardGroupComputeRedundancyCapacity` – DB シャードグループのスタンバイインスタンスによって消費された ACU の数。
+ `DBShardGroupMaxACU` – DB シャードグループに設定された ACU の最大数。
+ `DBShardGroupMinACU` – DB シャードグループで必要な ACU の最小数。
`DBShardGroupIdentifier` ディメンションキーは、`DBShardGroup` メトリクスの集約に使用できます。
## DBShardGroupRouterAggregation メトリクス
CloudWatch コンソールで Aurora PostgreSQL Limitless Database の `DBShardGroupRouterAggregation` メトリクスを表示するには、**[RDS]**、**[DBShardGroupRouterAggregation]** の順に選択します。
次の CloudWatch メトリクスを追跡できます。
+ `CommitThroughput` – DB シャードグループ内のすべてのルーターノード間の 1 秒あたりのコミット操作の平均数。
+ `DatabaseConnections` – DB シャードグループ内のすべてのルーターノード間のすべての接続の合計数。
## DBShardGroupInstance メトリクス
DBShardGroupInstance は、各シャードまたはルーターサブクラスター内の個々の DB インスタンスです。
CloudWatch コンソールで Aurora PostgreSQL Limitless Database の `DBShardGroupInstance` メトリクスを表示するには、**[RDS]**、**[DBShardGroupInstance]** の順に選択します。
次の CloudWatch メトリクスを追跡できます。
+ `ACUUtilization` – `ServerlessDatabaseCapacity` メトリクスを、サブクラスターに割り当てられた最大 ACU 値で割って算出したパーセンテージ。
+ `AuroraReplicaLag` - コンピューティングの冗長性が有効になっている Limitless クラスターの場合、これはサブクラスター内のプライマリインスタンスから更新をレプリケートする際の遅延の量です。
+ `AuroraReplicaLagMaximum` – コンピューティング冗長が有効になっている Limitless クラスターの場合、これはサブクラスター内のプライマリインスタンスから更新をレプリケートする際の最大遅延量です。リードレプリカを削除または名前変更すると、古いリソースがリサイクルされるため、レプリケーション遅延が一時的に急増する可能性があります。このメトリクスを使用して、いずれかのリーダーでの高いレプリケーション遅延により、フェイルオーバーが発生したかどうかを判断します。
+ `AuroraReplicaLagMinimum` – コンピューティングの冗長性が有効になっている Limitless クラスターの場合、これはサブクラスター内のプライマリインスタンスから更新をレプリケートする際の最小遅延量です。
+ `BufferCacheHitRatio` – インスタンスのメモリキャッシュ (ストレージボリュームではなく) から提供されるデータとインデックスの割合。
+ `CommitLatency` – エンジンとストレージが特定のノード (ルーターまたはシャード) に対するコミット操作を完了するための平均所要時間。
+ `CommitThroughput` - 1 秒あたりのコミット操作の平均回数。
+ `CPUUtilization` – サブクラスターに割り当てられた最大 ACU 値のパーセンテージとしての CPU 使用率。
+ `FreeableMemory` – シャードグループを最大容量にスケールしたときに利用できる未使用のメモリ量。これは、シャードグループに割り当てられた ACU によって決まります。現在の容量が最大容量を下回る ACU ごとに、この値は約 2 GiB 増加します。したがって、DB シャードグループを上限にスケールアップするまで、このメトリクスはゼロに近づきません。
+ `MaximumUsedTransactionIDs` – 最も古い未バキュームトランザクション ID の古さ (トランザクション数単位)。この値が 2,146,483,648 (2^31 - 1,000,000) に達した場合、トランザクション ID の循環を防ぐためにデータベースは読み取り専用モードになります。詳細については、PostgreSQL ドキュメントの [Preventing transaction ID wraparound failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) を参照してください。
+ `NetworkReceiveThroughput` - DB シャードグループ内の各インスタンスが各クライアントから受信したネットワークスループットの量。DB シャードグループとクラスターボリューム内のインスタンス間のネットワークトラフィックは、このスループットに含まれません。
+ `NetworkThroughput` – クライアントとルーター、および DB シャードグループ内のルーターとシャード間の集約ネットワークスループット (送受信の両方)。DB シャードグループとクラスターボリューム内のインスタンス間のネットワークトラフィックは、このスループットに含まれません。
+ `NetworkTransmitThroughput` - DB シャードグループ内の各インスタンスが各クライアントに対して送信したネットワークスループットの量。DB シャードグループとクラスターボリューム内のインスタンス間のネットワークトラフィックは、このスループットに含まれません。
+ `ReadIOPS` – 1 秒あたりのディスク読み取り入出力オペレーション (IOPS) の平均回数。
+ `ReadLatency` – 1 回のディスク読み取り入出力 (I/O) オペレーションにかかる平均時間。
+ `ReadThroughput` – 1 秒あたりのディスクからの平均読み取りバイト数。
+ `ServerlessDatabaseCapacity` – DB シャードグループ内の DB シャードまたはルーターサブクラスターの現在の容量。
+ `StorageNetworkReceiveThroughput` - DB シャードグループ内の各インスタンスが Aurora ストレージサブシステムから受信したネットワークスループットの量。
+ `StorageNetworkThroughput` - DB シャードグループ内の各インスタンスが Aurora ストレージサブシステムから送受信した集約ネットワークスループットの量。
+ `StorageNetworkTransmitThroughput` - DB シャードグループ内の各インスタンスが Aurora ストレージサブシステムに対して送信したネットワークスループットの量。
+ `SwapUsage` – DB シャードグループが使用するスワップ領域の量。
+ `TempStorageIOPS` – DB インスタンスにアタッチされたローカルストレージで実行された I/O オペレーションの平均回数。これには、読み取りおよび書き込み I/O オペレーションの両方が含まれます。
`TempStorageIOPS` を `TempStorageThroughput` と組み合わせて使用することで、DB インスタンスとローカルストレージデバイス間の転送におけるネットワークアクティビティが予期しない容量増加の原因となるようなまれなケースを診断できます。
+ `TempStorageThroughput` – ルーターまたはシャードに関連付けられたローカルストレージとの間で転送されたデータ量。
+ `WriteIOPS` – ディスク書き込み IOPS の平均回数。
+ `WriteLatency` – 1 回のディスク書き込み I/O オペレーションにかかる平均時間。
+ `WriteThroughput` – 1 秒あたりのディスクへの平均書き込みバイト数。
次のディメンションキーは、`DBShardGroupInstance` メトリクスの集約に使用できます。
+ `DBClusterIdentifier` – Aurora PostgreSQL DB クラスター。
+ `DBShardGroupIdentifier` – インスタンスが属する DB シャードグループ。
+ `DBShardGroupSubClusterType` – ノードタイプ。`Distributed Transaction Router` (ルーター) または `Data Access Shard` (シャード) のいずれか。
+ `DBShardGroupSubClusterIdentifier` – インスタンスが属するルーターまたはシャードの名前。
次の例は、CloudWatch メトリクスの集約を示しています。
+ DB シャードグループ内の特定のシャードまたはルーターに属するすべてのインスタンスの合計 `CPUUtilization`。
+ DB シャードグループ内のすべてのインスタンスの合計 `CPUUtilization`。
## DBClusterIdentifier メトリクス
CloudWatch コンソールで Aurora PostgreSQL Limitless Database の `DBClusterIdentifier` メトリクスを表示するには、**[RDS]**、**[DBClusterIdentifier]** の順に選択します。
Aurora PostgreSQL Limitless Database を使用する場合、Aurora DB クラスターの場合よりも多くの入出力 (I/O) オペレーションが発生する可能性があります。Limitless Database クラスターの次の CloudWatch メトリクスを追跡できます。
+ `VolumeReadIops` – クラスターボリュームからの請求対象の読み取り I/O オペレーションの回数 (5 分間隔で報告されます)。
+ `VolumeWriteIops` – クラスターボリュームに対する書き込みディスク I/O オペレーションの回数 (5 分間隔で報告されます)。
Aurora PostgreSQL Limitless Database は、Aurora I/O-Optimized クラスターストレージ設定を使用します。Aurora I/O-Optimized では、100 万件の I/O リクエストごとに料金を支払うのではなく、すべての I/O オペレーションに対して 1 回の月額料金を支払います。詳細については、「[Amazon Aurora DB クラスターのストレージ設定](Aurora.Overview.StorageReliability.md#aurora-storage-type)」を参照してください。
Aurora DB クラスターの場合よりも多くのストレージを使用する可能性もあります。ストレージの次の CloudWatch メトリクスを追跡できます。
+ `BackupRetentionPeriodStorageUsed` – Aurora PostgreSQL Limitless Database クラスターの請求対象の継続的なバックアップストレージの合計使用量。
+ `SnapshotStorageUsed` – Aurora PostgreSQL Limitless Database クラスターの請求対象のスナップショットストレージの合計使用量。
+ `TotalBackupStorageBilled` – 自動バックアップ保持と DB クラスタースナップショットのコストの合計。
バックアップストレージコストの詳細については、「[Amazon Aurora バックアップストレージの使用状況を確認する](aurora-storage-backup.md)」を参照してください。
+ `VolumeBytesUsed` – Aurora PostgreSQL Limitless Database クラスターで使用されるストレージの量 (5 分間隔で報告されます)。
# CloudWatch Database Insights による Aurora PostgreSQL Limitless Database のモニタリング
Database Insights のスタンダードモードは、Aurora PostgreSQL Limitless Database を有効にするために必要です。これを使用して、Limitless Database DB インスタンスのデータベース負荷 (DB 負荷) をリアルタイムでモニタリングできます。DB 負荷は、データベース内のセッションアクティビティのレベルを測定するものです。Database Insights を使用して、Aurora PostgreSQL Limitless Database DB インスタンスのパフォーマンスを大規模に分析およびトラブルシューティングできます。
CloudWatch Database Insights の詳細については、次を参照してください。
+ [CloudWatch Database Insights による Amazon Aurora データベースのモニタリング](USER_DatabaseInsights.md)
+ 「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html)」
+ 「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch Database Insights の使用を開始する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html)」
+ [Amazon Aurora の Database Insights でスロー SQL クエリをモニタリングするようにデータベースを設定する](USER_DatabaseInsights.SlowSQL.md)
Database Insights のアドバンストモードまたはスタンダードモードを有効にする方法については、以下のトピックを参照してください。
**Topics**
+ [Aurora PostgreSQL Limitless Database の Database Insights のアドバンストモードを有効にする](limitless-monitoring.cwdbi.advanced.md)
+ [Aurora PostgreSQL Limitless Database の Database Insights のスタンダードモードを有効にする](limitless-monitoring.cwdbi.standard.md)
# Aurora PostgreSQL Limitless Database の Database Insights のアドバンストモードを有効にする
Aurora PostgreSQL Limitless Database の Database Insights のアドバンストモードを有効にするには、次の手順を使用します。
## Aurora PostgreSQL Limitless Database の DB クラスターを作成するときに Database Insights のアドバンストモードを有効にする
Aurora PostgreSQL Limitless Database のデータベースを作成するときに、Database Insights のアドバンストモードを有効にします。
------
#### [ Console ]
コンソールで、DB クラスターを作成するときに Database Insights のアドバンストモードを有効にできます。Database Insights の設定は、DB クラスター内のすべての DB インスタンスに適用されます。
**コンソールを使用して DB クラスターを作成するときに Database Insights のアドバンストモードを有効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. **[データベースの作成]** を選択します。
1. **[Database Insights]** セクションで **[アドバンストモード]** を選択し、次のいずれかのオプションを選択します。
+ **保持期間** - Performance Insights データを保持する期間。Database Insights のアドバンストモードでは、保持期間は 15 ～ 24 か月とする必要があります。
+ **AWS KMS key** - KMS キーを指定します。Performance Insights は、潜在的に機密性の高いすべてのデータを KMS キーを使用して暗号化します。データは、転送中と不使用時のいずれも暗号化されます。詳細については、「[Amazon Aurora リソースの暗号化](Overview.Encryption.md)」を参照してください。
1. **[データベースの作成]** を選択します。
------
#### [ AWS CLI ]
DB クラスターの作成時に Database Insights のアドバンストモードを有効にするには、[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI コマンドを呼び出し、次の値を指定します。
+ `--db-cluster-identifier` – DB クラスターの識別子。
+ `--database-insights-mode advanced` – Database Insights のアドバンストモードを有効にします。
+ `--engine` – DB クラスターは `aurora-postgresql` DB エンジンを使用する必要があります。
+ `--engine-version` – DB クラスターは以下の DB エンジンバージョンのいずれかを使用する必要があります。
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` – DB クラスターは `aurora-iopt1` DB クラスターストレージ設定を使用する必要があります。
+ `--cluster-scalability-type` – Aurora DB クラスターのスケーラビリティモードを指定します。`limitless` に設定すると、クラスターは Aurora PostgreSQL Limitless Database として動作します。`standard` (デフォルト) に設定すると、クラスターは通常の DB インスタンスの作成を使用します。
**注記**
DB クラスターの作成後にこの設定を変更することはできません。
+ `--master-username` – DB クラスターのマスターユーザーの名前。
+ `--master-user-password` – マスターユーザーのパスワード。
+ `--enable-performance-insights` – Database Insights の Performance Insights を有効にします。
+ `--performance-insights-retention-period` – DB クラスターのデータの保持期間。Database Insights を有効にするには、保持期間を 465 日以上にする必要があります。
+ `--monitoring-interval` – DB クラスターの拡張モニタリングメトリクスを収集するポイント間の間隔 (秒単位)。この値を `0` にすることはできません。
+ `--monitoring-role-arn` – RDS が拡張モニタリングメトリクスを Amazon CloudWatch Logs に送信することを許可する IAM ロールの Amazon リソースネーム (ARN)。
+ `--enable-cloudwatch-logs-exports` – CloudWatch Logs に `postgresql` ログをエクスポートする必要があります。
次の例では、DB クラスターの作成時に Database Insights のアドバンストモードを有効にします。
Linux、macOS、Unix の場合:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode advanced \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 465 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Windows の場合:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode advanced ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 465 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
DB クラスターの作成時に Database Insights のアドバンストモードを有効にするには、[CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API オペレーションに次のパラメータを指定します。
+ `DatabaseInsightsMode`～`advanced`
+ `Engine`～`aurora-postgresql`
+ `EngineVersion` を Limitless Database で使用可能なエンジンバージョンへ
+ `StorageType`～`aurora-iopt1`
+ `ClusterScalabilityType`～`limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights`～`True`
+ `PerformanceInsightsRetentionPeriod` を `465` 日以上に
+ `MonitoringInterval` を `0` ではない値に
+ `MonitoringRoleArn` をRDS が拡張モニタリングメトリクスを Amazon CloudWatch Logs に送信することを許可する IAM ロールの Amazon リソースネーム (ARN) に。
------
## Aurora PostgreSQL Limitless Database の DB クラスターを変更するときに Database Insights のアドバンストモードを有効にする
Aurora PostgreSQL Limitless Database のデータベースを変更するときに Database Insights を有効にします。
**注記**
Database Insights を有効にするには、DB クラスター内の各 DB インスタンスに、同じ Performance Insights と拡張モニタリング設定が必要です。
------
#### [ Console ]
コンソールで、DB クラスターを変更するときに Database Insights のアドバンストモードを有効にできます。Database Insights の設定は、DB クラスター内のすべての DB インスタンスに適用されます。
**コンソールを使用して DB クラスターを変更するときに Database Insights のアドバンストモードを有効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. DB クラスターを選択し、**[変更]** を選択します。
1. **[Database Insights]** セクションで **[アドバンストモード]** を選択し、次のいずれかのオプションを選択します。
+ **保持期間** - Performance Insights データを保持する期間。Database Insights のアドバンストモードでは、保持期間は 15 ～ 24 か月とする必要があります。
+ **AWS KMS key** - KMS キーを指定します。Performance Insights は、潜在的に機密性の高いすべてのデータを KMS キーを使用して暗号化します。データは、転送中と不使用時のいずれも暗号化されます。詳細については、「[Amazon Aurora リソースの暗号化](Overview.Encryption.md)」を参照してください。
1. [**続行**] を選択します。
1. [**Scheduling of Modifications**] で、[**Apply immediately**] を選択します。**[スケジュールされた次回のメンテナンス時間帯に適用]** を選択すると、データベースではこの設定が無視され、Database Insights のアドバンストモードが直ちに有効になります。
1. [**クラスタークラスターの変更**] を選択します。
------
#### [ AWS CLI ]
DB クラスターの変更時に Database Insights のアドバンストモードを有効にするには、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI コマンドを呼び出し、次の値を指定します。
+ `--database-insights-mode advanced` – Database Insights のアドバンストモードを有効にします。
+ `--db-cluster-identifier` – DB クラスターの識別子。
+ `--enable-performance-insights` – Database Insights の Performance Insights を有効にします。
+ `--performance-insights-retention-period` – DB クラスターのデータの保持期間。Database Insights のアドバンストモードを有効にするには、保持期間を 465 日以上にする必要があります。
次の例では、DB クラスターの変更時に Database Insights のアドバンストモードを有効にします。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--database-insights-mode advanced \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 465
```
Windows の場合:
```
aws rds modify-db-cluster ^
--database-insights-mode advanced ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 465
```
------
#### [ RDS API ]
DB クラスターの変更時に Database Insights のアドバンストモードを有効にするには、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API オペレーションに次のパラメータを指定します。
+ `DatabaseInsightsMode`～`advanced`
+ `EnablePerformanceInsights`～`True`
+ `PerformanceInsightsRetentionPeriod` を `465` 日以上に
------
# Aurora PostgreSQL Limitless Database の Database Insights のスタンダードモードを有効にする
Aurora PostgreSQL Limitless Database で Database Insights のスタンダードモードを有効にするには、次の手順を使用します。
## Aurora PostgreSQL Limitless Database の DB クラスターを作成するときに Database Insights のスタンダードモードを有効にする
Aurora PostgreSQL Limitless Database のデータベースを作成するときに、Database Insights のスタンダードモードを有効にします。
------
#### [ Console ]
コンソールで、DB クラスターを作成するときに Database Insights のスタンダードモードを有効にできます。Database Insights の設定は、DB クラスター内のすべての DB インスタンスに適用されます。
**コンソールを使用して DB クラスターを作成するときに Database Insights のスタンダードモードを有効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. **[データベースの作成]** を選択します。
1. **[Database Insights]** セクションで **[スタンダードモード]** を選択し、次のいずれかのオプションを選択します。
+ **保持期間** - Performance Insights データを保持する期間。Aurora PostgreSQL Limitless Database の DB クラスターを作成するには、保持期間が 31 日以上である必要があります。
+ **AWS KMS key** - KMS キーを指定します。Performance Insights は、潜在的に機密性の高いすべてのデータを KMS キーを使用して暗号化します。データは、転送中と不使用時のいずれも暗号化されます。詳細については、「[Amazon Aurora リソースの暗号化](Overview.Encryption.md)」を参照してください。
1. **[データベースの作成]** を選択します。
------
#### [ AWS CLI ]
DB クラスターの作成時に Database Insights のスタンダードモードを有効にするには、[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI コマンドを呼び出し、次の値を指定します。
+ `--db-cluster-identifier` – DB クラスターの識別子。
+ `--database-insights-mode standard` – Database Insights のスタンダードモードを有効にします。
+ `--engine` – DB クラスターは `aurora-postgresql` DB エンジンを使用する必要があります。
+ `--engine-version` – DB クラスターは以下の DB エンジンバージョンのいずれかを使用する必要があります。
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` – DB クラスターは `aurora-iopt1` DB クラスターストレージ設定を使用する必要があります。
+ `--cluster-scalability-type` – Aurora DB クラスターのスケーラビリティモードを指定します。`limitless` に設定すると、クラスターは Aurora PostgreSQL Limitless Database として動作します。`standard` (デフォルト) に設定すると、クラスターは通常の DB インスタンスの作成を使用します。
**注記**
DB クラスターの作成後にこの設定を変更することはできません。
+ `--master-username` – DB クラスターのマスターユーザーの名前。
+ `--master-user-password` – マスターユーザーのパスワード。
+ `--enable-performance-insights` – Database Insights の Performance Insights を有効にします。
+ `--performance-insights-retention-period` – DB クラスターのデータの保持期間。Aurora PostgreSQL Limitless Database の DB クラスターを作成するには、保持期間が 31 日以上である必要があります。
+ `--monitoring-interval` – DB クラスターの拡張モニタリングメトリクスを収集するポイント間の間隔 (秒単位)。この値を `0` にすることはできません。
+ `--monitoring-role-arn` – RDS が拡張モニタリングメトリクスを Amazon CloudWatch Logs に送信することを許可する IAM ロールの Amazon リソースネーム (ARN)。
+ `--enable-cloudwatch-logs-exports` – CloudWatch Logs に `postgresql` ログをエクスポートする必要があります。
次の例では、DB クラスターの作成時に Database Insights のスタンダードモードを有効にします。
Linux、macOS、Unix の場合:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode standard \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 31 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Windows の場合:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode standard ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 31 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
DB クラスターの作成時に Database Insights のスタンダードモードを有効にするには、[CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API オペレーションに次のパラメータを指定します。
+ `DatabaseInsightsMode`～`standard`
+ `Engine`～`aurora-postgresql`
+ `EngineVersion` を Limitless Database で使用可能なエンジンバージョンへ
+ `StorageType`～`aurora-iopt1`
+ `ClusterScalabilityType`～`limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights`～`True`
+ `PerformanceInsightsRetentionPeriod` を `31` 日以上に
+ `MonitoringInterval` を `0` ではない値に
+ `MonitoringRoleArn` をRDS が拡張モニタリングメトリクスを Amazon CloudWatch Logs に送信することを許可する IAM ロールの Amazon リソースネーム (ARN) に。
------
## Aurora PostgreSQL Limitless Database の DB クラスターを変更するときに Database Insights のスタンダードモードを有効にする
Aurora PostgreSQL Limitless Database のデータベースを変更するときに Database Insights を有効にします。
**注記**
Database Insights を有効にするには、DB クラスター内の各 DB インスタンスに、同じ Performance Insights と拡張モニタリング設定が必要です。
------
#### [ Console ]
コンソールで、DB クラスターを作成するときに Database Insights のスタンダードモードを有効にできます。Database Insights の設定は、DB クラスター内のすべての DB インスタンスに適用されます。
**コンソールを使用して DB クラスターを変更するときに Database Insights のスタンダードモードを有効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. DB クラスターを選択し、**[変更]** を選択します。
1. **[Database Insights]** セクションで **[スタンダードモード]** を選択し、次のいずれかのオプションを選択します。
+ **保持期間** - Performance Insights データを保持する期間。Aurora PostgreSQL Limitless Database の DB クラスターを作成するには、保持期間が 31 日以上である必要があります。
+ **AWS KMS key** - KMS キーを指定します。Performance Insights は、潜在的に機密性の高いすべてのデータを KMS キーを使用して暗号化します。データは、転送中と不使用時のいずれも暗号化されます。詳細については、「[Amazon Aurora リソースの暗号化](Overview.Encryption.md)」を参照してください。
1. [**続行**] を選択します。
1. [**Scheduling of Modifications**] で、[**Apply immediately**] を選択します。**[スケジュールされた次回のメンテナンス時間帯に適用]** を選択すると、データベースではこの設定が無視され、Database Insights のスタンダードモードが直ちに有効になります。
1. [**クラスタークラスターの変更**] を選択します。
------
#### [ AWS CLI ]
DB クラスターの変更時に Database Insights のスタンダードモードを有効にするには、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI コマンドを呼び出し、次の値を指定します。
+ `--db-cluster-identifier` – DB クラスターの識別子。
+ `--database-insights-mode standard` – Database Insights のスタンダードモードを有効にします。
+ `--enable-performance-insights` – Database Insights の Performance Insights を有効にします。
+ `--performance-insights-retention-period` – DB クラスターのデータの保持期間。Database Insights のスタンダードモードを有効にするには、保持期間を 31 日以上にする必要があります。
次の例では、DB クラスターの変更時に Database Insights のスタンダードモードを有効にします。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--database-insights-mode standard \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 31
```
Windows の場合:
```
aws rds modify-db-cluster ^
--database-insights-mode standard ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 31
```
------
#### [ RDS API ]
DB クラスターの変更時に Database Insights のスタンダードモードを有効にするには、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API オペレーションに次のパラメータを指定します。
+ `DatabaseInsightsMode`～`standard`
+ `EnablePerformanceInsights`～`True`
+ `PerformanceInsightsRetentionPeriod` を `31` 日以上に
------
# Amazon CloudWatch Logs による Aurora PostgreSQL Limitless Database のモニタリング
Aurora PostgreSQL Limitless Database を有効にするには、PostgreSQL ログを CloudWatch Logs にエクスポートする必要があります。標準 Aurora PostgreSQL DB クラスターの PostgreSQL ログにアクセスする場合と同様に、CloudWatch Logs Insights でこれらのログにアクセスして分析できます。詳細については、「[CloudWatch Logs Insights を使用した PostgreSQL のログ分析](AuroraPostgreSQL.CloudWatch.Analyzing.md)」を参照してください。
DB クラスターのロググループ名は、Aurora PostgreSQL と同じです。
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
DB シャードグループのロググループ名は、次の形式になります。
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
ノード (ルーターまたはシャード) ごとにログストリームがあります。その名前は以下の形式になります。
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
以下に例を示します。
+ ルーター – `DistributedTransactionRouter/6-6.2`
+ シャード – `DataAccessShard/22-22.0`
**注記**
DB クラスターの場合とは異なり、DB シャードグループの PostgreSQL ログファイルは、RDS コンソール、AWS CLI、または RDS API で直接表示することはできません。CloudWatch Logs Insights を使用して表示する必要があります。
# 拡張モニタリングによる Aurora PostgreSQL Limitless Database のモニタリング
Aurora PostgreSQL Limitless Database を有効にするには、拡張モニタリングが必要です。これを使用して、Limitless Database DB インスタンスのオペレーティングシステムをリアルタイムでモニタリングできます。
Aurora は CloudWatch Logs に拡張モニタリングメトリクスを公開します。利用可能な主なメトリクスには、データベース接続、ストレージ使用量、クエリレイテンシーなどがあります。これらはパフォーマンスのボトルネックの特定に役立ちます。
拡張モニタリングのメトリクスの詳細については、「[Aurora の OS メトリクス](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS)」を参照してください。
# Performance Insights による Aurora PostgreSQL Limitless Database のモニタリング
Performance Insights を使用して、Aurora PostgreSQL Limitless Database クラスターをモニタリングします。Performance Insights は、Aurora PostgreSQL Limitless Database でも、標準の Aurora DB クラスターと同様に機能します。ただし、Aurora PostgreSQL Limitless Database ではシャードグループレベルでメトリクスを追跡します。
追跡する 2 つの主要な Performance Insights メトリクスは次のとおりです。
+ データベース負荷 – データベース内のアクティビティのレベルを測定します。毎秒収集されるPerformance Insights のキーメトリクスは `DBLoad` です。
Performance Insights の `DBLoad` メトリクスの単位は、平均アクティブセッション (AAS) です。平均アクティブセッションを取得するため、Performance Insights はクエリを同時に実行しているセッションの数をサンプリングします。AAS は、特定期間の総セッション数を総サンプル数で割った値です。`DBLoad` と AAS の詳細については、「[データベース負荷](USER_PerfInsights.Overview.ActiveSessions.md)」を参照してください。
+ 最大 CPU — データベースで使用できる最大計算能力。アクティブなセッションが最大 CPU を超えているかどうかを確認するには、`Max vCPU` 行との関係を調べます。`Max vCPU` 値は、DB インスタンスの vCPU (仮想 CPU) のコア数によって決まります。`Max vCPU` の詳細については、「[最大 CPU 容量](USER_PerfInsights.Overview.MaxCPU.md)」をご参照ください。
さらに、`DBLoad` メトリクスを*ディメンション*に「スライス」できます。ディメンションは、メトリクスのサブカテゴリです。最も有用なディメンションは次のとおりです。
+ 上位のインスタンス — インスタンス (シャードとルーター) の相対的な DB 負荷を降順に表示します。
+ 待機イベント – SQL ステートメントが特定のイベントが発生するまで待機してから、実行を続行するようにします。待機イベントは、作業が妨げられる場所を示します。
+ 上位の SQL — DB の負荷に最も寄与しているクエリを示します。
Performance Insights ディメンションの詳細については、「[ディメンション](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions)」を参照してください。
次の図は、DB シャードグループの**上位のインスタンス**ディメンションを示しています。
![\[DB シャードグループの上位のインスタンスディメンション。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の DB 負荷を分析する](USER_PerfInsights.AnalyzeLimitlessTables.md)
# Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の DB 負荷を分析する
Performance Insights を使用して、Aurora PostgreSQL Limitless Database のメトリクスをシャードグループレベルとインスタンスレベルで追跡できます。Aurora PostgreSQL Limitless Database の DB 負荷を分析するときは、各シャードとルーターの DB 負荷を最大 vCPU と比較することが必要になります。
**注記**
Aurora PostgreSQL Limitless Database では、常に Performance Insights と拡張モニタリングが有効になっています。Limitless Database の Performance Insights データの最小保持期間は 31 日 (1 か月) です。
**[絶対]** ビューには、平均アクティブセッション (AAS) の数と推定 vCPU が表示されます。**[相対]** ビューには、推定 vCPU に対する AAS の比率が表示されます。
**Topics**
+ [Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の相対的な DB 負荷を分析する](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の DB 負荷を待機別に分析する](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の負荷分散を分析する](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の相対的な DB 負荷を分析する
相対的な DB 負荷を追跡することで、Aurora PostgreSQL Limitless Database のパフォーマンスを向上させることができます。Aurora PostgreSQL Limitless Database の相対的な DB 負荷をインスタンス別に分析するには、次の手順を使用します。
**コンソールを使用して Aurora PostgreSQL Limitless Database の相対的な DB 負荷を分析するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Performance Insights ダッシュボードが表示されます。
1. **[データベース負荷 (DB 負荷)]** セクションの **[分類方法]** で **[インスタンス]** を選択します。Aurora PostgreSQL Limitless Database のすべてのインスタンスの vCPU コアに対する平均アクティブセッション (AAS) の比率を確認するには、**[表示]** で **[相対]** を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
![\[Aurora PostgreSQL Limitless Database のインスタンス別に分類された Performance Insights ダッシュボードが表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. 上位インスタンスを表示するには、**[上位のインスタンス]** タブを選択します。
次の例では、DB 負荷が最も高いインスタンスは `DTR-2-2` です。
![\[Aurora PostgreSQL Limitless Database のインスタンス別に分類された [上位のインスタンス] タブを使用します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. (オプション) Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷を分析するには、**[インスタンス]** 列でインスタンス名を選択します。`DTR-2-2` の DB 負荷を表示するには、**[インスタンス]** 列で `DTR-2-2` を選択します。
**注記**
Performance Insights メトリクスは、Aurora PostgreSQL Limitless Database のインスタンスについてのみ表示できます。
# Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の DB 負荷を待機別に分析する
待機イベントを追跡することで、Aurora PostgreSQL Limitless Database のパフォーマンスを向上させることができます。Aurora PostgreSQL Limitless Database の DB 負荷を待機イベント別に分析するには、次の手順を使用します。
**コンソールを使用して Aurora PostgreSQL Limitless Database の DB 負荷を待機イベント別に分析するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Performance Insights ダッシュボードが表示されます。
1. **[データベース負荷 (DB 負荷)]** セクションの **[分類方法]** で **[待機]** を選択します。AAS の数と推定 vCPU を表示するには、**[表示]** で **[絶対]** を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
![\[待機別に分類されています。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. 下部にある [**トップ SQL**] タブまでスクロールします。
次の例では、待機による負荷が最も高い SQL ステートメントは `DELETE` ステートメントです。
![\[待機別に分類された場合の [トップ SQL] タブ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. SQL ステートメントを選択して展開し、コンポーネントステートメントを表示します。
次の例では、`SELECT` ステートメントに 3 つのコンポーネントステートメントがあります。
![\[SQL ステートメントを選択して展開します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# Performance Insights ダッシュボードを使用して Aurora PostgreSQL Limitless Database の負荷分散を分析する
Aurora PostgreSQL Limitless Database でインスタンスの負荷分散のバランスを取ることができます。Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を分析するには、次の手順を使用します。
**コンソールを使用して Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を分析するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Performance Insights ダッシュボードが表示されます。
1. **[データベース負荷 (DB 負荷)]** セクションの **[分類方法]** で **[インスタンス]** を選択します。Aurora PostgreSQL Limitless Database のすべてのインスタンスの AAS の数と推定 vCPU を表示するには、**[表示]** で **[絶対]** を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
![\[Aurora PostgreSQL Limitless Database のインスタンス別に分類された Performance Insights の絶対ダッシュボードが表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を示すグラフを表示するには、**[負荷分散]** タブを選択します。
次の例では、DB 負荷が最も高いインスタンスは `DTR-2-2` です。
![\[インスタンスレベルで待機別に分類した場合の [トップ SQL] タブ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Amazon GuardDuty RDS Protection による Aurora PostgreSQL Limitless Database のモニタリング
Amazon GuardDuty は、AWS 環境内のアカウント、コンテナ、ワークロード、データを保護する脅威検知サービスです。GuardDuty は、機械学習（ML）モデル、異常および脅威検出機能を使用して、さまざまなログソースとランタイムアクティビティを継続的に監視し、環境内の潜在的なセキュリティリスクと悪意のあるアクティビティを特定して優先順位を付けます。
Amazon GuardDuty RDS Protection は、Amazon Aurora データベースに対する潜在的なアクセス脅威がないか、ログインイベントを分析してプロファイリングします。RDS Protection を有効にすると、GuardDuty は Aurora データベースの RDS ログインイベントを消費します。RDS Protection は、これらのイベントを監視し、潜在的な内部脅威や外部アクターがないかプロファイリングします。
Aurora での GuardDuty RDS Protection の詳細については、「[Amazon Aurora に対する Amazon GuardDuty RDS Protection による脅威のモニタリング](guard-duty-rds-protection.md)」を参照してください。
GuardDuty RDS Protection の有効化の詳細については、「*Amazon GuardDuty ユーザーガイド*」の「[GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html)」を参照してください。
# Aurora PostgreSQL Limitless Database の関数とビュー
Aurora PostgreSQL Limitless Database に関数とビューが追加されました。これらは、対応する Aurora PostgreSQL の関数とビューに基づいています。
**注記**
進行中のトランザクションがある場合、一部の統計は一貫性のない結果を返す可能性があります。
**Topics**
+ [Aurora PostgreSQL Limitless Database 関数](limitless-monitoring-functions.md)
+ [Aurora PostgreSQL Limitless Database ビュー](limitless-monitoring-views.md)
# Aurora PostgreSQL Limitless Database 関数
次の表は、Aurora PostgreSQL Limitless Database の新しい関数を示しています。
**注記**
この表に表示されている関数は、`rds_aurora` スキーマにあります。Limitless Database 関数を使用する場合は、完全修飾オブジェクト名 `rds_aurora`.`object_name` を必ず含めてください。
| Aurora PostgreSQL Limitless Database 関数 | 対応する Aurora PostgreSQL 関数 |
| --- | --- |
| [limitless\$1backend\$1dsid](#limitless_backend_dsid) | pg\$1backend\$1pid |
| [limitless\$1cancel\$1session](#limitless_cancel_session) | pg\$1cancel\$1backend |
| [limitless\$1stat\$1clear\$1snapshot](#limitless_stat_clear_snapshot) | pg\$1stat\$1clear\$1snapshot |
| [limitless\$1stat\$1database\$1size](#limitless_stat_database_size) | pg\$1database\$1size |
| [limitless\$1stat\$1get\$1snapshot\$1timestamp](#limitless_stat_get_snapshot_timestamp) | pg\$1stat\$1get\$1snapshot\$1timestamp |
| [limitless\$1stat\$1prepared\$1xacts](#limitless_stat_prepared_xacts) | pg\$1prepared\$1xacts |
| [limitless\$1stat\$1relation\$1sizes](#limitless_stat_relation_sizes) | pg\$1indexes\$1size、pg\$1relation\$1size、pg\$1table\$1size、pg\$1total\$1relation\$1size |
| [limitless\$1stat\$1reset](#limitless_stat_reset) | pg\$1stat\$1reset |
| [limitless\$1stat\$1statements\$1reset](#limitless_stat_statements_reset) | pg\$1stat\$1statements\$1reset |
| [limitless\$1stat\$1system\$1waits](#limitless_stat_system_waits) | aurora\$1stat\$1system\$1waits |
| [limitless\$1terminate\$1session](#limitless_terminate_session) | pg\$1terminate\$1backend |
| [limitless\$1wait\$1report](#limitless_wait_report) | aurora\$1wait\$1report |
次の例は、Aurora PostgreSQL Limitless Database 関数の詳細を示しています。PostgreSQL 関数の詳細については、PostgreSQL ドキュメントの「[Functions and operators](https://www.postgresql.org/docs/15/functions.html)」を参照してください。
**limitless\$1backend\$1dsid**
`limitless_backend_dsid` 関数は、現在のセッションの分散セッション ID を返します。分散セッションは、DB シャードグループのルーターで実行され、DB シャードグループの 1 つ以上のシャードでバックエンドプロセスが関与します。
以下の例は、`limitless_backend_dsid` 関数の使用方法を示しています。
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
`limitless_cancel_session` 関数は `pg_cancel_backend` と同様に動作しますが、`SIGINT` (中断信号) を送信することで、提供された分散セッション ID に関連するすべてのバックエンドプロセスをキャンセルしようとします。
入力パラメータは次のとおりです。
+ `distributed_session_id` (テキスト) – キャンセルする分散セッションの ID。
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `pid` (テキスト) – バックエンドプロセス ID。
+ `success` (ブール値) — キャンセルが成功したかどうか。
以下の例は、`limitless_cancel_session` 関数の使用方法を示しています。
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
`limitless_stat_clear_snapshot` 関数は、現在の統計スナップショットまたはキャッシュされた情報をすべてのノードで破棄します。
以下の例は、`limitless_stat_clear_snapshot` 関数の使用方法を示しています。
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
`limitless_stat_database_size` 関数は、DB シャードグループ内のデータベースのサイズを返します。
入力パラメータは次のとおりです。
+ `dbname` (名前) – サイズを取得するデータベース。
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `db_size` – このサブクラスター内のデータベースのサイズ (バイト単位)。
以下の例は、`limitless_stat_database_size` 関数の使用方法を示しています。
```
SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless');
subcluster_id | subcluster_type | db_size
---------------+-----------------+----------
1 | router | 8895919
2 | router | 8904111
3 | shard | 21929391
4 | shard | 21913007
5 | shard | 21831087
(5 rows)
```
**limitless\$1stat\$1get\$1snapshot\$1timestamp**
`limitless_stat_get_snapshot_timestamp` 関数は、現在の統計スナップショットのタイムスタンプ、または統計スナップショットが作成されていない場合は `NULL` を返します。`stats_fetch_consistency` が `snapshot` に設定されている場合、トランザクションで累積統計に初めてアクセスしたときにスナップショットが作成されます。すべてのノードからのスナップショットのタイムスタンプの統合ビューを返します。`subcluster_id` 列 と `subcluster_type` 列には、データのソースとなるノードが表示されます。
以下の例は、`limitless_stat_get_snapshot_timestamp` 関数の使用方法を示しています。
```
SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp();
subcluster_id | subcluster_type | snapshot_timestamp
---------------+-----------------+--------------------
1 | router |
2 | router |
3 | shard |
4 | shard |
5 | shard |
(5 rows)
```
**limitless\$1stat\$1prepared\$1xacts**
`limitless_stat_prepared_xacts` 関数は、現在 2 フェーズコミット用に準備されているすべてのノードのトランザクションに関する情報を返します。詳細については、PostgreSQL ドキュメントの「[pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html)」を参照してください。
以下の例は、`limitless_stat_prepared_xacts` 関数の使用方法を示しています。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts;
subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id
---------------+-----------------+----------------+------------------------------+-------------------------------+------------+--------------------
8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless
12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless
(2 rows)
```
**limitless\$1stat\$1relation\$1sizes**
`limitless_stat_relation_sizes` 関数は、DB シャードグループのテーブルのさまざまなサイズを返します。
入力パラメータは次のとおりです。
+ `relnspname` (名前) – テーブルを含むスキーマの名前。
+ `relname` (名前) – テーブルの名前。
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `main_size` – このノードのメインデータフォークのサイズ (バイト単位)。
+ `fsm_size` – このノードのテーブルの空き容量マップのサイズ (バイト単位)。
+ `vm_size` – このノードのテーブルの可視性マップのサイズ (バイト単位)。
+ `init_size` – このノードのテーブルの初期化のサイズ (バイト単位)。
+ `toast_size` – このフォークのテーブルに関連付けられたトーストテーブルのサイズ (バイト単位)。
+ `index_size` – このノードのテーブルのすべてのインデックスのサイズ (バイト単位)。
+ `total_size` – このノードのテーブルのすべてのセグメントのサイズ (バイト単位)。
次の例は、`limitless_stat_relation_sizes` 関数の使用方法を示しています (一部の列は省略されています)。
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers');
subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size
---------------+-----------------+-----------+----------+---------+------------+------------+------------
1 | router | 0 | 0 | 0 | 0 | 0 | 0
2 | router | 0 | 0 | 0 | 0 | 0 | 0
3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432
(5 rows)
```
**limitless\$1stat\$1reset**
`limitless_stat_reset` 関数は、現在のデータベースのすべての統計カウンターをゼロ (0) にリセットします。`track_functions` が有効になっている場合、`limitless_stat_database` の `stats_reset` 列には、データベースの統計が最後にリセットされた時刻が表示されます。デフォルトでは、`limitless_stat_reset` はスーパーユーザーのみが実行できます。他のユーザーには、`EXECUTE` 権限を使用してアクセス許可を付与できます。
以下の例は、`limitless_stat_reset` 関数の使用方法を示しています。
```
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
--------------+-------------
896 | 0
(1 row)
SELECT rds_aurora.limitless_stat_reset();
limitless_stat_reset
---------------------
(1 row)
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
-------------+-------------
0 | 0
(1 row)
```
**limitless\$1stat\$1statements\$1reset**
`limitless_stat_statements_reset` 関数は、指定された `username`、`dbname`、`distributed_query_id`、`queryid` パラメータに対応する、`limitless_stat_statements` によってこれまで収集された統計を破棄します。パラメータのいずれかが指定されていない場合、デフォルト値 `""` または `0` (無効) が各パラメータに使用され、他のパラメータと一致する統計がリセットされます。パラメータが指定されていない場合、または指定されたすべてのパラメータが `""` または `0` (無効) である場合、関数はすべての統計を破棄します。`limitless_stat_statements` ビュー内のすべての統計が破棄された場合、関数は `limitless_stat_statements_info` ビューの統計もリセットします。
入力パラメータは次のとおりです。
+ `username` (名前) – ステートメントをクエリしたユーザー。
+ `dbname` (名前) – クエリを実行したデータベース。
+ `distributed_query_id` (bigint) – コーディネーターノードからの親クエリのクエリ ID。親クエリの場合、この列は `NULL` です。コーディネーターノードは分散クエリ ID を参加ノードにプッシュダウンします。したがって、参加ノードでは、分散クエリ ID とクエリ ID の値が異なります。
+ `queryid` (bigint) – ステートメントのクエリ ID。
次の例は、`limitless_stat_statements_reset` 関数を使用して、`limitless_stat_statements` によって収集されたすべての統計をリセットする方法を示しています。
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
`limitless_stat_system_waits` 関数は、`aurora_stat_system_waits` からの待機イベントデータの統合ビューを返します。このビューは、すべてのノードからインスタンス内のシステム全体の待機アクティビティを報告します。`subcluster_id` 列 と `subcluster_type` 列には、データのソースとなるノードが表示されます。
以下の例は、`limitless_stat_system_waits` 関数の使用方法を示しています。
```
postgres_limitless=> SELECT *
FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe
WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler';
subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name
---------------+-----------------+---------+-----------+--------+--------------+------------------------
1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler
2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler
3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler
4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler
5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler
(5 rows)
```
**limitless\$1terminate\$1session**
`limitless_terminate_session` 関数は `pg_terminate_backend` と同様に動作しますが、`SIGTERM` (終了信号) を送信することで、提供された分散セッション ID に関連するすべてのバックエンドプロセスを終了しようとします。
入力パラメータは次のとおりです。
+ `distributed_session_id` (テキスト) — 終了する分散セッションの ID。
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `pid` (テキスト) – バックエンドプロセス ID。
+ `success` (ブール値) – プロセスが正常に終了したかどうか。
以下の例は、`limitless_terminate_session` 関数の使用方法を示しています。
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
`limitless_wait_report` 関数は、すべてのノードからの一定期間の待機イベントアクティビティを返します。`subcluster_id` 列 と `subcluster_type` 列には、データのソースとなるノードが表示されます。
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
残りの列は `aurora_wait_report` と同じです。
以下の例は、`limitless_wait_report` 関数の使用方法を示しています。
```
postgres_limitless=> select * from rds_aurora.limitless_wait_report();
subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +-------------
1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237
5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276
4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147
2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810
3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86
```
# Aurora PostgreSQL Limitless Database ビュー
次の表は、Aurora PostgreSQL Limitless Database の新しいビューを示しています。
**注記**
この表に表示されているビューは、`rds_aurora` スキーマにあります。Limitless Database ビューを使用する場合は、完全修飾オブジェクト名 `rds_aurora`.`object_name` を必ず含めてください。
| Aurora PostgreSQL Limitless Database ビュー | 対応する Aurora PostgreSQL ビュー |
| --- | --- |
| [limitless\$1database](#limitless_database) | pg\$1database |
| [limitless\$1locks](#limitless_locks) | pg\$1locks |
| [limitless\$1stat\$1activity](#limitless_stat_activity) | pg\$1stat\$1activity |
| [limitless\$1stat\$1all\$1indexes](#limitless_stat_all_indexes) | pg\$1stat\$1all\$1indexes |
| [limitless\$1stat\$1all\$1tables](#limitless_stat_all_tables) | pg\$1stat\$1all\$1tables |
| [limitless\$1stat\$1database](#limitless_stat_database) | pg\$1stat\$1database |
| [limitless\$1stat\$1progress\$1vacuum](#limitless_stat_progress_vacuum) | pg\$1stat\$1progress\$1vacuum |
| [limitless\$1stat\$1statements](#limitless_stat_statements) | pg\$1stat\$1statements |
| [limitless\$1stat\$1subclusters](#limitless_stat_subclusters) | なし |
| [limitless\$1stat\$1statements\$1info](#limitless_stat_statements_info) | pg\$1stat\$1statements\$1info |
| [limitless\$1statio\$1all\$1indexes](#limitless_statio_all_indexes) | pg\$1statio\$1all\$1indexes |
| [limitless\$1statio\$1all\$1tables](#limitless_statio_all_tables) | pg\$1statio\$1all\$1tables |
| [limitless\$1tables](#limitless_tables) | pg\$1tables |
| [limitless\$1table\$1collocations](#limitless_table_collocations) | なし |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | なし |
次の例は、Aurora PostgreSQL Limitless Database ビューの詳細を示しています。PostgreSQL ビューの詳細については、PostgreSQL ドキュメントの「[Viewing statistics](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS)」を参照してください。
**注記**
進行中のトランザクションがある場合、一部の統計ビューは一貫性のない結果を返す可能性があります。
**limitless\$1database**
このビューには、DB シャードグループで使用可能なデータベースに関する情報が含まれています。例:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, oid, datname, datacl FROM rds_aurora.limitless_database;
subcluster_id | subcluster_type | oid | datname | datacl
---------------+-----------------+-------+--------------------+------------------------------------------------------------------------------------------------------------------------
2 | router | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
2 | router | 5 | postgres |
2 | router | 16384 | rdsadmin | {rdsadmin=CTc/rdsadmin,rds_aurora_limitless_metadata_admin=c/rdsadmin,rds_aurora_limitless_heat_mgmt_admin=c/rdsadmin}
2 | router | 16477 | postgres_limitless |
2 | router | 1 | template1 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
6 | shard | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – サブクラスター (ノード) の ID
+ `subcluster_type` (テキスト) – サブクラスター (ノード）、ルーター、シャードのタイプ
残りの列は `pg_database` と同じです。
**limitless\$1locks**
このビューには、各ノードのプロセスごとに 1 行が含まれます。データベースサーバー内のアクティブなプロセスによって保持されるロックに関する情報へのアクセスを提供します。
**Example 2 つのトランザクションを伴うロックの作成**
この例では、2 つのルーターで 2 つのトランザクションを同時に実行します。
```
# Transaction 1 (run on router 1)
BEGIN;
SET search_path = public;
SELECT * FROM customers;
INSERT INTO customers VALUES (400,'foo','bar');
# Transaction 2 (run on router 2)
BEGIN;
SET search_path = public;
ALTER TABLE customers ADD COLUMN phone VARCHAR;
```
最初のトランザクションが実行されます。後続のトランザクションは、最初のトランザクションが完了するまで待つ必要があります。したがって、2 番目のトランザクションはロックでブロックされます。その根本原因を確認するには、`limitless_locks` と `limitless_stat_activity` を結合してコマンドを実行します。
```
# Run on router 2
SELECT distributed_session_id, state, usename, query, query_start
FROM rds_aurora.limitless_stat_activity
WHERE distributed_session_id in (
SELECT distributed_session_id
FROM rds_aurora.limitless_locks
WHERE relname = 'customers'
);
distributed_session_id | state | usename | query | query_start
------------------------+---------------------+--------------------------+---------------------------------- -------------+-------------------------------
47BDE66E9A5E8477 | idle in transaction | limitless_metadata_admin | INSERT INTO customers VALUES (400,'foo','bar'); | 2023-04-13 17:44:45.152244+00
2AD7F370202D0FA9 | active | limitless_metadata_admin | ALTER TABLE customers ADD COLUMN phone VARCHAR; | 2023-04-13 17:44:55.113388+00
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
(6 rows)
```
**Example ロックを明示的に作成する**
この例では、明示的にロックを作成し、`limitless_locks` ビューを使用してロックを表示します (一部の列は省略されます)。
```
BEGIN;
SET search_path = public;
LOCK TABLE customers IN ACCESS SHARE MODE;
SELECT * FROM rds_aurora.limitless_locks WHERE relname = 'customers';
subcluster_id | subcluster_type | distributed_session_id | locktype | datname | relnspname | relname | virtualtransaction | pid | mode
---------------+-----------------+------------------------+----------+--------------------+------------+ ----------+--------------------+-------+-----------------
1 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600787 | 59564 | AccessShareLock
2 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600405 | 67130 | AccessShareLock
3 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 15/473401 | 27735 | AccessShareLock
4 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473524 | 27734 | AccessShareLock
5 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/472935 | 27737 | AccessShareLock
6 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473015 | 48660 | AccessShareLock
(6 rows)
```
**limitless\$1stat\$1activity**
このビューには、各ノードのプロセスごとに 1 行が含まれます。システム全体の状態を追跡し、時間がかかっているプロセスをトリアージするために使用できます。例:
```
postgres=# SELECT
subcluster_id,
subcluster_type,
distributed_session_id,
distributed_session_state,
datname,
distributed_query_id,
is_sso_query
FROM
rds_aurora.limitless_stat_activity
WHERE
distributed_session_id in ('D2470C97E3D07E06', '5A3CD7B8E5FD13FF')
order by distributed_session_id;
subcluster_id | subcluster_type | distributed_session_id | distributed_session_state | datname | distributed_query_id | is_sso_query
---------------+-----------------+------------------------+---------------------------+--------------------+----------------------+--------------
2 | router | 5A3CD7B8E5FD13FF | coordinator | postgres_limitless | | f
3 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
4 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
2 | router | D2470C97E3D07E06 | coordinator | postgres_limitless | | t
3 | shard | D2470C97E3D07E06 | participant | postgres_limitless | 4058400544464210222 |
(5 rows)
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `distributed_session_id` (テキスト) – このプロセスが属する分散セッションの ID。
+ `distributed_session_state` (テキスト) – これがコーディネーター、参加者、スタンドアロン/非分散プロセス (`NULL` と表示) であるかどうか。
+ `datname` (テキスト) – このプロセスが接続されているデータベース。
+ `distributed_query_id` (bigint) – コーディネーターノードからの親クエリのクエリ ID。親クエリの場合、この列は `NULL` です。コーディネーターノードは分散クエリ ID を参加ノードにプッシュダウンします。したがって、参加ノードでは、分散クエリ ID とクエリ ID の値が異なります。
+ `is_sso_query` (テキスト) – これにより、クエリが単一シャード最適化されているかどうかがわかります。
残りの列は `pg_stat_activity` と同じです。
**limitless\$1stat\$1all\$1indexes**
このビューには、DB シャードグループのインデックスの使用統計が含まれます。例:
```
postgres_limitless=> SELECT schemaname, relname, indexrelname, idx_scan
FROM rds_aurora.limitless_stat_all_indexes
WHERE relname LIKE 'orders_ts%' ORDER BY indexrelname LIMIT 10;
schemaname | relname | indexrelname | idx_scan
------------+----------------+---------------------+----------
ec_sample | orders_ts00001 | orders_ts00001_pkey | 196801
ec_sample | orders_ts00002 | orders_ts00002_pkey | 196703
ec_sample | orders_ts00003 | orders_ts00003_pkey | 196376
ec_sample | orders_ts00004 | orders_ts00004_pkey | 197966
ec_sample | orders_ts00005 | orders_ts00005_pkey | 195301
ec_sample | orders_ts00006 | orders_ts00006_pkey | 195673
ec_sample | orders_ts00007 | orders_ts00007_pkey | 194475
ec_sample | orders_ts00008 | orders_ts00008_pkey | 191694
ec_sample | orders_ts00009 | orders_ts00009_pkey | 193744
ec_sample | orders_ts00010 | orders_ts00010_pkey | 195421
(10 rows)
```
**limitless\$1stat\$1all\$1tables**
このビューには、DB シャードグループの現在のデータベース内のすべてのテーブルに関する統計が含まれます。これは、バキューム操作とデータ操作言語 (DML) 操作を追跡する場合に役立ちます。例:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, relname, n_ins_since_vacuum, n_tup_ins, last_vacuum
FROM rds_aurora.limitless_stat_all_tables
WHERE relname LIKE 'orders_ts%' ORDER BY relname LIMIT 10;
subcluster_id | subcluster_type | relname | n_ins_since_vacuum | n_tup_ins | last_vacuum
---------------+-----------------+----------------+--------------------+-----------+-------------
5 | shard | orders_ts00001 | 34779 | 196083 |
5 | shard | orders_ts00002 | 34632 | 194721 |
5 | shard | orders_ts00003 | 34950 | 195965 |
5 | shard | orders_ts00004 | 34745 | 197283 |
5 | shard | orders_ts00005 | 34879 | 195754 |
5 | shard | orders_ts00006 | 34340 | 194605 |
5 | shard | orders_ts00007 | 33779 | 192203 |
5 | shard | orders_ts00008 | 33826 | 191293 |
5 | shard | orders_ts00009 | 34660 | 194117 |
5 | shard | orders_ts00010 | 34569 | 195560 |
(10 rows)
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `relname` (名前) – テーブルの名前。
残りの列は `pg_stat_all_tables` と同じです。
**limitless\$1stat\$1database**
このビューには、DB シャードグループ内のすべてのデータベースに関する統計が含まれます。各ノードのデータベースごとに 1 行を返します。例:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
datname,
blks_read,
blks_hit
FROM
rds_aurora.limitless_stat_database
WHERE
datname='postgres_limitless';
subcluster_id | subcluster_type | datname | blks_read | blks_hit
---------------+-----------------+--------------------+-----------+----------
1 | router | postgres_limitless | 484 | 34371314
2 | router | postgres_limitless | 673 | 33859317
3 | shard | postgres_limitless | 1299 | 17749550
4 | shard | postgres_limitless | 1094 | 17492849
5 | shard | postgres_limitless | 1036 | 17485098
6 | shard | postgres_limitless | 1040 | 17437257
(6 rows)
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `datname` (名前) – データベースの名前。
残りの列は `pg_stat_database` と同じです。
**limitless\$1stat\$1progress\$1vacuum**
このビューには、進行中のバキューム操作に関する情報が含まれています。例:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
-[ RECORD 1 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | A56D96E2A5C9F426
pid | 5270
datname | postgres
nspname | public
relname | customer_ts2
phase | vacuuming heap
heap_blks_total | 130500
heap_blks_scanned | 100036
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 11184810
num_dead_tuples | 0
-[ RECORD 2 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | 56DF26A89EC23AB5
pid | 6854
datname | postgres
nspname | public
relname | sales_ts1
phase | vacuuming heap
heap_blks_total | 43058
heap_blks_scanned | 24868
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 8569523
num_dead_tuples | 0
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `distributed_session_id` (テキスト) – バキューム操作を開始したセッションの識別子。
+ `datname` (名前) – バキューム処理が実行されているデータベース。
+ `nspname` (名前) – バキューム処理が実行されているテーブルのスキーマの名前。バキューム処理されているテーブルが、ユーザーが接続されているデータベースと同じデータベースにない場合、これは `null` です。
+ `relname` (名前) – バキューム処理が実行されているテーブルの名前。バキューム処理されているテーブルが、ユーザーが接続されているデータベースと同じデータベースにない場合、これは `null` です。
残りの列は `pg_stat_progress_vacuum` と同じです。
**limitless\$1stat\$1statements**
このビューは、すべてのノードで実行されるすべての SQL ステートメントの計画統計と実行統計を追跡する手段を提供します。
`limitless_stat_statements` ビューを使用するには、[pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) 拡張機能をインストールする必要があります。
```
-- CREATE EXTENSION must be run by a superuser
CREATE EXTENSION pg_stat_statements;
-- Verify that the extension is created on all nodes in the DB shard group
SELECT distinct node_id
FROM rds_aurora.limitless_stat_statements
LIMIT 10;
```
以下の例は、`limitless_stat_statements` ビューの使用例です。
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
distributedqueryid,
username,
dbname,
sso_calls
FROM
rds_aurora.limitless_stat_statements;
subcluster_id | subcluster_type | distributedqueryid | username | dbname | sso_calls
---------------+-----------------+----------------------+-------------------------------------+--------------------+-----------
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 1
3 | shard | -7975178695405682176 | postgres | postgres_limitless |
[...]
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
+ `subcluster_type` (テキスト) – このプロセスが属するサブクラスターのタイプ: `router` または `shard`。
+ `distributedqueryid` (bigint) – コーディネーターノードからの親クエリのクエリ ID。親クエリの場合、この列は `NULL` です。コーディネーターノードは分散クエリ ID を参加ノードにプッシュダウンします。したがって、参加ノードでは、分散クエリ ID とクエリ ID の値が異なります。
+ `username` (名前) – ステートメントをクエリしたユーザー。
+ `dbname` (名前) – クエリを実行したデータベース。
+ `sso_calls` (名前) – ステートメントが単一シャード最適化された回数。
残りの列は [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) と同じです。
**limitless\$1stat\$1statements\$1info**
このビューには、`limitless_stat_statements` ビューの統計が含まれます。各行には、各ノードの [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) ビューのデータが含まれます。`subcluster_id` 列は各ノードを識別します。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_statements_info;
subcluster_id | subcluster_type | dealloc | stats_reset
---------------+-----------------+---------+-------------------------------
1 | router | 0 | 2023-06-30 21:22:09.524781+00
2 | router | 0 | 2023-06-30 21:21:40.834111+00
3 | shard | 0 | 2023-06-30 21:22:10.709942+00
4 | shard | 0 | 2023-06-30 21:22:10.740179+00
5 | shard | 0 | 2023-06-30 21:22:10.774282+00
6 | shard | 0 | 2023-06-30 21:22:10.808267+00
(6 rows)
```
出力パラメータは次のとおりです。
+ `subcluster_id` (テキスト) – このプロセスが属するサブクラスターの ID。
残りの列は [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) と同じです。
**limitless\$1stat\$1subclusters**
このビューには、ルーターと他のノード間のネットワーク統計が含まれます。ルーターと他のノードのペアごとに 1 行が含まれます。次に例を示します。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_subclusters;
orig_subcluster | orig_instance_az | dest_subcluster | dest_instance_az | latency_us | latest_collection | failed_requests | received_bytes | sent_bytes | same_az_requests | cross_az_requests | stat_reset_timestamp
-----------------+------------------+-----------------+------------------+------------+-------------------------------+-----------------+----------------+------------+------------------+-------------------+-------------------------------
3 | us-west-2b | 2 | us-west-2a | 847 | 2024-10-07 17:25:39.518617+00 | 0 | 35668633 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.239675+00
3 | us-west-2b | 4 | us-west-2b | 419 | 2024-10-07 17:25:39.546376+00 | 0 | 101190464 | 248795719 | 883478 | 0 | 2024-10-05 12:39:55.231218+00
3 | us-west-2b | 5 | us-west-2c | 1396 | 2024-10-07 17:25:39.52122+00 | 0 | 72864849 | 172086292 | 0 | 557726 | 2024-10-05 12:39:55.196412+00
3 | us-west-2b | 6 | us-west-2c | 729 | 2024-10-07 17:25:39.54828+00 | 0 | 35668584 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.247334+00
3 | us-west-2b | 7 | us-west-2a | 1702 | 2024-10-07 17:25:39.545307+00 | 0 | 71699576 | 171634844 | 0 | 556278 | 2024-10-05 12:39:52.715168+00
2 | us-west-2a | 3 | us-west-2b | 868 | 2024-10-07 17:25:40.293927+00 | 0 | 35659611 | 92011872 | 0 | 302817 | 2024-10-05 12:39:54.420758+00
2 | us-west-2a | 4 | us-west-2b | 786 | 2024-10-07 17:25:40.296863+00 | 0 | 102437253 | 251838024 | 0 | 895060 | 2024-10-05 12:39:54.404081+00
2 | us-west-2a | 5 | us-west-2c | 1232 | 2024-10-07 17:25:40.292021+00 | 0 | 71990027 | 168828110 | 0 | 545453 | 2024-10-05 12:39:36.769549+00
```
出力パラメータは次のとおりです。
+ `orig_subcluster` (テキスト) – 通信の発信元のルーターの ID
+ `orig_subcluster_az` (テキスト) – 発信元ルーターのアベイラビリティーゾーン (AZ)
+ `dest_subcluster` (テキスト) – 送信先ノードの ID
+ `dest_subcluster_az` (テキスト) – 送信先ノードの最後に収集された AZ
+ `latency_us` (bigint) — ノード間で最後に収集されたネットワークレイテンシー (マイクロ秒単位)。ノードに到達できない場合、値は `0` です。
+ `latest_collection` (タイムスタンプ) — 送信先ノードの AZ とレイテンシーの最新収集時のタイムスタンプ
+ `failed_requests` (bigint) – 失敗した内部リクエストの累積数
+ `received_bytes` (bigint) — このノードから受信した推定累積バイト数
+ `sent_bytes` (bigint) - このノードに送信された推定累積バイト数
+ `same_az_requests` (bigint) – 発信元ルーターと同じ AZ にある場合の、このノードへの内部 DB リクエストの累積数
+ `cross_az_requests` (bigint) – 発信元ルーターとは異なる AZ にある場合の、このノードへの内部 DB リクエストの累積数
+ `stat_reset_timestamp` (タイムスタンプ) – このビューの累積統計が最後にリセットされたときのタイムスタンプ
**limitless\$1statio\$1all\$1indexes**
このビューには、DB シャードグループ内のすべてのインデックスの入出力 (I/O) 統計が含まれます。例:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_statio_all_indexes WHERE relname like'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
---------------+-----------------+------------+-------------------+-------------------------------------+ --------------+--------------
3 | shard | public | customers_ts00002 | customers_ts00002_customer_name_idx | 1 | 0
3 | shard | public | customers_ts00001 | customers_ts00001_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00003 | customers_ts00003_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00004 | customers_ts00004_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00005 | customers_ts00005_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00006 | customers_ts00006_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00007 | customers_ts00007_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00008 | customers_ts00008_customer_name_idx | 1 | 0
(8 rows)
```
**limitless\$1statio\$1all\$1tables**
このビューには、DB シャードグループ内のすべてのテーブルの入出力 (I/O) 統計が含まれます。例:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
schemaname,
relname,
heap_blks_read,
heap_blks_hit
FROM
rds_aurora.limitless_statio_all_tables
WHERE
relname LIKE 'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | heap_blks_read | heap_blks_hit
---------------+-----------------+------------+-------------------+----------------+---------------
3 | shard | public | customers_ts00002 | 305 | 57780
3 | shard | public | customers_ts00001 | 300 | 56972
4 | shard | public | customers_ts00004 | 302 | 57291
4 | shard | public | customers_ts00003 | 302 | 57178
5 | shard | public | customers_ts00006 | 300 | 56932
5 | shard | public | customers_ts00005 | 302 | 57386
6 | shard | public | customers_ts00008 | 300 | 56881
6 | shard | public | customers_ts00007 | 304 | 57635
(8 rows)
```
**limitless\$1tables**
このビューには、Aurora PostgreSQL Limitless Database のテーブルに関する情報が含まれます。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables;
table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key
-----------+-----------+-------------+-------------+--------------+-------------+------------------
5 | 18635 | public | placeholder | active | placeholder |
6 | 18641 | public | ref | active | reference |
7 | 18797 | public | orders | active | sharded | HASH (order_id)
2 | 18579 | public | customer | active | sharded | HASH (cust_id)
(4 rows)
```
**limitless\$1table\$1collocations**
このビューには、コロケーションされたシャードテーブルに関する情報が含まれます。
次の例では、`orders` テーブルと `customers` テーブルがコロケーションされ、`users` テーブルと `followers` テーブルがコロケーションされています。コロケーションテーブルの `collocation_id` は同じです。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id;
collocation_id | schema_name | table_name
----------------+-------------+------------
2 | public | orders
2 | public | customers
5 | public | users
5 | public | followers
(4 rows)
```
**limitless\$1table\$1collocation\$1distributions**
このビューには、各コロケーションのキー分散が表示されます。
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound;
collocation_id | subcluster_id | lower_bound | upper_bound
----------------+---------------+----------------------+----------------------
2 | 6 | -9223372036854775808 | -4611686018427387904
2 | 5 | -4611686018427387904 | 0
2 | 4 | 0 | 4611686018427387904
2 | 3 | 4611686018427387904 | 9223372036854775807
5 | 6 | -9223372036854775808 | -4611686018427387904
5 | 5 | -4611686018427387904 | 0
5 | 4 | 0 | 4611686018427387904
5 | 3 | 4611686018427387904 | 9223372036854775807
(8 rows)
```
# Aurora PostgreSQL Limitless Database の待機イベント
Aurora PostgreSQL の待機イベントは、入出力 (I/O) やロックなど、セッションが待機しているリソースを示します。待機イベントは、セッションがリソースを待機している理由を判断し、ボトルネックを特定するのに役立ちます。詳細については、「[Aurora PostgreSQL の待機イベント](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits)」を参照してください。
Aurora PostgreSQL Limitless Database には、ルーターとシャードに関連する独自の待機イベントがあります。その多くは、シャードがタスクを完了するのを待っているルーターに関するものです。シャード待機イベントには、実行中のタスクの詳細が含まれます。
**Topics**
+ [待機イベントのクエリ](#limitless-monitoring-waits.query)
+ [Limitless Database 待機イベント](limitless-waits-reference.md)
## 待機イベントのクエリ
次の例に示すように、[limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) ビューを使用して待機イベントをクエリできます。
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
次の例に示すように、`aurora_stat_system_waits` 関数を使用して、待機回数と、各待機イベントで費やした合計時間を一覧表示することもできます。
```
postgres_limitless=> SELECT type_name,event_name,waits,wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type()
WHERE type_name='AuroraLimitless'
ORDER BY wait_time DESC;
type_name | event_name | waits | wait_time
-----------------+---------------------------+---------+-------------
AuroraLimitless | RemoteStatementSetup | 7518 | 75236507897
AuroraLimitless | RemoteStatementExecution | 40 | 132986
AuroraLimitless | Connect | 5 | 1453
(3 rows)
```
# Limitless Database 待機イベント
Aurora PostgreSQL Limitless Database には、次の待機イベントが適用されます。これらの待機イベントをモニタリングして、Aurora PostgreSQL Limitless Database の処理におけるボトルネックを特定できます。
**Topics**
+ [IO:TwophaseFilePoolWrite 待機イベント](#limitless-waits-TwophaseFilePoolWrite)
+ [IO:TwophaseFilePoolRead 待機イベント](#limitless-waits-TwophaseFilePoolRead)
+ [AuroraLimitless:Connect 待機イベント](#limitless-waits-Connect)
+ [AuroraLimitless:AsyncConnect 待機イベント](#limitless-waits-AsyncConnect)
+ [AuroraLimitless:RemoteStatementSetup 待機イベント](#limitless-waits-RemoteStatementSetup)
+ [AuroraLimitless:RemoteDDLExecution 待機イベント](#limitless-waits-RemoteDDLExecution)
+ [AuroraLimitless:RemoteStatementExecution 待機イベント](#limitless-waits-RemoteStatementExecution)
+ [AuroraLimitless:FetchRemoteResults 待機イベント](#limitless-waits-FetchRemoteResults)
+ [AuroraLimitless:AsyncGetInitialResponse 待機イベント](#limitless-waits-AsyncGetInitialResponse)
+ [AuroraLimitless:AsyncGetNextResponse 待機イベント](#limitless-waits-AsyncGetNextResponse)
+ [AuroraLimitless:AbortedCommandCleanup 待機イベント](#limitless-waits-AbortedCommandCleanup)
+ [AuroraLimitless:DistributedCommitPrepare 待機イベント](#limitless-waits-DistributedCommitPrepare)
+ [AuroraLimitless:DistributedCommit 待機イベント](#limitless-waits-DistributedCommit)
+ [AuroraLimitless:DistributedCommitPrepareThrottle 待機イベント](#limitless-waits-DistributedCommitPrepareThrottle)
+ [AuroraLimitless:PreparedTransactionResolution 待機イベント](#limitless-waits-PreparedTransactionResolution)
+ [AuroraLimitless:SendPreparedTransactionOutcome 待機イベント](#limitless-waits-SendPreparedTransactionOutcome)
+ [AuroraLimitless:CommitClockBarrier 待機イベント](#limitless-waits-CommitClockBarrier)
+ [AuroraLimitless:SnapshotClockBarrier 待機イベント](#limitless-waits-SnapshotClockBarrier)
+ [AuroraLimitless:ReaderSnapshotClockBarrier 待機イベント](#limitless-waits-ReaderSnapshotClockBarrier)
+ [AuroraLimitless:GatherDistributedDeadlockGraph 待機イベント](#limitless-waits-GatherDistributedDeadlockGraph)
+ [AuroraLimitless:DistributedDeadlockDetection 待機イベント](#limitless-waits-DistributedDeadlockDetection)
+ [AuroraLimitless:DistributedDeadlockAbort 待機イベント](#limitless-waits-DistributedDeadlockAbort)
+ [AuroraLimitless:GatherRemoteStats 待機イベント](#limitless-waits-GatherRemoteStats)
+ [AuroraLimitless:GlobalSequenceRefresh 待機イベント](#limitless-waits-GlobalSequenceRefresh)
+ [AuroraLimitless:GlobalVacuumTimeExchange 待機イベント](#limitless-waits-GlobalVacuumTimeExchange)
+ [AuroraLimitless:DistributedTransactionMonitorGather 待機イベント](#limitless-waits-DistributedTransactionMonitorGather)
+ [AuroraLimitlessActivity:AdminTaskSchedulerMain 待機イベント](#limitless-waits-AdminTaskSchedulerMain)
+ [AuroraLimitlessActivity:AdminTaskExecutorMain 待機イベント](#limitless-waits-AdminTaskExecutorMain)
+ [AuroraLimitlessActivity:AdminTaskMonitorMain 待機イベント](#limitless-waits-AdminTaskMonitorMain)
+ [AuroraLimitlessActivity:DatabaseCleanupMonitorMain 待機イベント](#limitless-waits-DatabaseCleanupMonitorMain)
+ [AuroraLimitlessActivity:TopologyCleanupMonitorMain 待機イベント](#limitless-waits-TopologyCleanupMonitorMain)
+ [AuroraLimitlessActivity:ToplogyChangeMonitorMain 待機イベント](#limitless-waits-ToplogyChangeMonitorMain)
+ [AuroraLimitlessActivity:DistributedTransactionMonitorMain 待機イベント](#limitless-waits-DistributedTransactionMonitorMain)
+ [AuroraLimitlessActivity:GlobalVacuumMonitorMain 待機イベント](#limitless-waits-GlobalVacuumMonitorMain)
## IO:TwophaseFilePoolWrite 待機イベント
2 相状態のファイルプール内の 2 相状態のファイルの書き込みを待っています。これは Aurora 固有のイベントです。
### 原因
Limitless Database 分散トランザクションの参加者を含め、`PREPARED TRANSACTION` コマンドを実行するプロセスでは、トランザクションの状態を 2 相ファイルに保持する必要があります。Aurora は、ファイルプールを使用してこのオペレーションのパフォーマンスを向上させます。
### アクション
これは同期的な書き込み I/O オペレーションです。したがって、このイベントのレイテンシーが高い場合は、`IO:XactSync` と同様の原因があり、同じ方法で調査できます。Limitless Database を使用する場合は、実行される分散トランザクションの数を減らす必要が生じることがあります。
## IO:TwophaseFilePoolRead 待機イベント
2 相状態のファイルプール内の 2 相状態のファイルの読み取りを待っています。
### 原因
Limitless Database 分散トランザクションの参加者を含め、以前に準備されたトランザクションに対して `COMMIT PREPARED` コマンドを実行するプロセスでは、2 相ファイルから事前に保持されたトランザクション状態の読み取りが必要になる場合があります。Aurora は、ファイルプールを使用してこのオペレーションのパフォーマンスを向上させます。
### アクション
これは読み取り I/O オペレーションです。したがって、このイベントのレイテンシーが高い場合は、`IO:DataFileRead` と同様の原因があり、同じように調査できます。Limitless Database を使用する場合は、実行される分散トランザクションの数を減らす必要が生じることがあります。
## AuroraLimitless:Connect 待機イベント
プロセスは、クラスター内の別のノードへの接続が確立されるのを待っています。
### 原因
クエリ、分散トランザクション、DDL を実行するために、プロセスとリモートノードの間の接続が確立されます。
### アクション
クラスターへの同時接続数を減らすか、複数のシャードにまたがるクエリの使用を調整します。
## AuroraLimitless:AsyncConnect 待機イベント
このイベントは `Connect` に似ていますが、一連のノードへの並列接続が確立されるのを待つプロセスを表しています。
### 原因
並列接続の確立は、DDL ステートメントの実行時に最も一般的に行われます。
### アクション
DDL ステートメントの数を減らすか、同じセッションで複数の DDL を組み合わせて、接続をより適切に再利用します。
## AuroraLimitless:RemoteStatementSetup 待機イベント
プロセスは、カーソルのオープン、クローズ、プリペアドステートメントの作成など、リモートクエリ実行のセットアップを待っています。
### 原因
この待機イベントは、ステートメントの単一シャード最適化を行えなかったシャードテーブルのスキャン数に応じて増加します。
### アクション
クエリを最適化してスキャンオペレーションの数を減らしたり、単一シャード最適化の適格基準を引き上げたりします。
## AuroraLimitless:RemoteDDLExecution 待機イベント
プロセスは、リモート DDL コマンドが終了するのを待っています。
### 原因
DB シャードグループで DDL コマンドを発行するときは、オペレーションを確定する前に、他のルーターとシャードノードに分散する必要があります。一部の DDL オペレーションは、スキーマの変更に合わせてデータの調整が必要になるため、実行が長時間に及ぶ場合があります。
### アクション
実行時間が長い DDL コマンドを特定して、それらを最適化します。
## AuroraLimitless:RemoteStatementExecution 待機イベント
プロセスはリモートコマンドの終了を待っています。
### 原因
SQL コマンドがリモートノードで実行されています。このイベントは、`auto_analyze` やハートビートチェックなどの内部通信で頻繁に表示されます。
### アクション
limitless\$1stat\$1statements ビューを使用して、実行時間が長いコマンドを特定します。多くの場合、特にバックグラウンドワーカーや内部プロセスでは、これは想定されるイベントであり、アクションは必要ありません。
## AuroraLimitless:FetchRemoteResults 待機イベント
プロセスは、リモートノードから行を取得するのを待っています。
### 原因
この待機イベントは、シャードテーブルやリファレンステーブルなど、リモートテーブルから多数の行を取得すると増加する可能性があります。
### アクション
`limitless_stat_statements` ビューを使用して、最適化されていない `SELECT` クエリを特定します。必要なデータのみを取得するようにクエリを最適化します。`rds_aurora.limitless_maximum_adaptive_fetch_size` パラメータを調整することもできます。
## AuroraLimitless:AsyncGetInitialResponse 待機イベント
プロセスは、パイプラインモードがクエリ実行で使用されている場合に初期レスポンスを待っています。
### 原因
これは通常、単一シャードデータ配置を持つクエリのルーターからシャードへの実行時に表示され、通常の実行の一部として想定されるものです。
### アクション
これ以上、何もする必要はありません。
## AuroraLimitless:AsyncGetNextResponse 待機イベント
プロセスは、パイプラインモードがクエリ実行で使用されている場合に追加レスポンスを待っています。
### 原因
これは通常、単一シャードデータ配置を持つクエリのルーターからシャードへの実行時に表示され、通常の実行の一部として想定されるものです。
### アクション
これ以上、何もする必要はありません。
## AuroraLimitless:AbortedCommandCleanup 待機イベント
プロセスは、リモートクリーンアップクエリの結果を待っています。分散トランザクションが終了すると、シャードノードを適切な状態に戻すために、クリーンアップクエリがシャードノードに発行されます。
### 原因
エラーの検出が原因で、またはユーザーが明示的に ABORT コマンドを発行するか実行中のクエリをキャンセルしたことが原因でトランザクションが中止されると、トランザクションのクリーンアップが行われます。
### アクション
トランザクションのキャンセルの原因を調べます。
## AuroraLimitless:DistributedCommitPrepare 待機イベント
プロセスは分散トランザクションをコミットしており、すべての参加者が準備コマンドを承認するのを待っています。
### 原因
複数のノードを変更するトランザクションでは、分散コミットを実行する必要があります。参加ノードの `IO:TwophaseFilePoolWrite` イベントで長時間に及ぶ待機が生じると、それが原因となって `DistributedCommitPrepare` で長時間の待機が発生する場合があります。
### アクション
複数のノードのデータを変更するトランザクションの数を減らします。クラスターの他のノードの `IO:TwophaseFilePoolWrite` イベントを調査します。
## AuroraLimitless:DistributedCommit 待機イベント
プロセスは分散トランザクションをコミットしており、リード参加者がコミットコマンドを承認するのを待っています。
### 原因
複数のノードを変更するトランザクションでは、分散コミットを実行する必要があります。リード参加者の `IO:XactSync` イベントで長時間に及ぶ待機が生じると、それが原因となって `DistributedCommit` で長時間の待機が発生する場合があります。
### アクション
複数のノードのデータを変更するトランザクションの数を減らします。クラスターの他のノードの `IO:XactSync` イベントを調査します。
## AuroraLimitless:DistributedCommitPrepareThrottle 待機イベント
プロセスは分散トランザクションの準備を試みており、既存の準備済みトランザクションによりスロットリングされています。
### 原因
複数のノードを変更するトランザクションでは、分散コミットを実行する必要があります。これらのトランザクションの参加者は、コミットプロトコルの一環として準備オペレーションを実行する必要があります。Aurora では同時準備の数が制限されており、この制限を超えると、プロセスは `DistributedCommitPrepareThrottle` イベントで待機します。
### アクション
複数のノードのデータを変更するトランザクションの数を減らします。`IO:TwophaseFilePoolWrite` イベントで時間が長引くと、既存の準備済みトランザクションが蓄積され、新しい準備の試行がスロットリングされる可能性があるため、これらのイベントを調査します。
## AuroraLimitless:PreparedTransactionResolution 待機イベント
プロセスで、準備状態の分散トランザクションによって変更されたタプルが発生しました。分散トランザクションをスナップショットに表示するかどうかをプロセスが判断する必要があります。
### 原因
複数のノードを変更するトランザクションでは、準備フェーズを含む分散コミットを実行する必要があります。分散トランザクションの数が多い場合や、分散コミットでレイテンシーが増加した場合、他のプロセスで `PreparedTransactionResolution` 待機イベントが発生する可能性があります。
### アクション
複数のノードのデータを変更するトランザクションの数を減らします。分散コミット関連イベントの時間が長引くと、分散トランザクションのコミットパスのレイテンシーが増加する可能性があるため、これらのイベントを調査します。また、ネットワークと CPU の負荷を調査することもできます。
## AuroraLimitless:SendPreparedTransactionOutcome 待機イベント
プロセスは分散トランザクションをコーディネートしているノードで実行されており、別のプロセスがそのトランザクションの状態について問い合わせたか、プロセスが分散トランザクションをコミットして結果を参加者に送信しています。
### 原因
`PreparedTransactionResolution` 待機イベントが発生すると、プロセスはトランザクションコーディネーターにクエリを実行します。トランザクションコーディネーターのレスポンスで、SendPreparedTransactionOutcome が発生します。
### アクション
複数のノードのデータを変更するトランザクションの数を減らします。分散コミット関連のイベント、`IO:TwophaseFilePoolWrite` イベント、`IO:TwophaseFilePoolRead` イベントが原因で分散トランザクションのコミットパスのレイテンシーが増加する可能性があるため、これらのイベントを調査します。また、ネットワークと CPU の負荷を調査することもできます。
## AuroraLimitless:CommitClockBarrier 待機イベント
プロセスはトランザクションをコミットしており、割り当てられたコミット時間がクラスター内のすべてのノードで確実に過去となっていることを保証するために、待機する必要があります。
### 原因
CPU またはネットワークの飽和よってクロックドリフトが増加し、この待機イベントに時間が費やされる場合があります。
### アクション
クラスター内の CPU またはネットワークの飽和状態を調べます。
## AuroraLimitless:SnapshotClockBarrier 待機イベント
プロセスは、将来のクロックを持つ別のノードからスナップショット時間を受け取り、その時間に到達するのを待っています。
### 原因
これは通常、プロセスがシャードにプッシュダウンされた関数から結果を受け取り、ノード間にクロックドリフトが発生している場合に発生します。CPU またはネットワークの飽和よってクロックドリフトが増加し、この待機イベントに時間が費やされる場合があります。
### アクション
クラスター内の CPU またはネットワークの飽和状態を調べます。
## AuroraLimitless:ReaderSnapshotClockBarrier 待機イベント
このイベントは読み取りノードで発生します。プロセスは、プロセスのスナップショット時間の前に発生したすべての書き込みが適用されるように、読み取りノードが書き込みストリームを再生するのを待っています。
### 原因
Aurora レプリカの遅延が増加すると、このイベントでの待機時間が長くなる可能性があります。
### アクション
Aurora レプリカの遅延を調査します。
## AuroraLimitless:GatherDistributedDeadlockGraph 待機イベント
プロセスは他のノードと通信して、分散デッドロック検出の一環としてロックグラフを収集しています。
### 原因
ロックの待機中、待機時間が `rds_aurora.limitless_distributed_deadlock_timeout` を超えると、プロセスは分散デッドロックチェックを実行します。
### アクション
アプリケーションのロック競合の原因を調査し、`rds_aurora.limitless_distributed_deadlock_timeout` の調整を検討します。
## AuroraLimitless:DistributedDeadlockDetection 待機イベント
プロセスは、分散デッドロックを検出するために他のノードと通信しています。
### 原因
ロックの待機中、待機時間が `rds_aurora.limitless_distributed_deadlock_timeout` を超えると、プロセスは分散デッドロックチェックを実行します。
### アクション
アプリケーションのロック競合の原因を調査し、`rds_aurora.limitless_distributed_deadlock_timeout` の調整を検討します。
## AuroraLimitless:DistributedDeadlockAbort 待機イベント
プロセスは、分散デッドロックの対象として選択されたセッションを中止するために、別のノードと通信しています。
### 原因
アプリケーションパターンが分散デッドロックを引き起こしています。
### アクション
分散デッドロックの原因となっているアプリケーションパターンを調査します。
## AuroraLimitless:GatherRemoteStats 待機イベント
プロセスは、クラスター内の他のノードから統計を収集しています。
### 原因
`limitless_stat_activity` などのモニタリングまたはアクティビティクエリおよびビューが、他のノードから統計を取得しようとしています。
### アクション
これ以上、何もする必要はありません。
## AuroraLimitless:GlobalSequenceRefresh 待機イベント
プロセスは、新しいシーケンス値を生成しており、グローバルシーケンスから新しいチャンクをリクエストする必要があります。
### 原因
`rds_aurora.limitless_sequence_chunk_size` が不十分な場合、シーケンス値の生成率が高いと、このイベントで停止が発生する可能性があります。
### アクション
この発生は正常です。このイベントで時間が長すぎる場合は、`rds_aurora.limitless_sequence_chunk_size` の調整を検討してください。Limitless Database のシーケンスに関するドキュメントを参照してください。
## AuroraLimitless:GlobalVacuumTimeExchange 待機イベント
プロセスは、バキュームをサポートするためにスナップショットデータを交換しています。
### 原因
Limitless Database のノードは、最も古いアクティブなスナップショット時間データを他のノードと交換して、バキューム実行の正しいカットオフ時間を計算します。
### アクション
これ以上、何もする必要はありません。
## AuroraLimitless:DistributedTransactionMonitorGather 待機イベント
プロセスは、分散トランザクションのクリーンアップをサポートするために、他のノードからトランザクションメタデータを収集しています。
### 原因
Limitless Database のノードは、トランザクションメタデータを他のノードと交換して、分散トランザクションの状態を消去できるタイミングを判断します。
### アクション
これ以上、何もする必要はありません。
## AuroraLimitlessActivity:AdminTaskSchedulerMain 待機イベント
タスクスケジューラプロセスのメインループで待機しています。
## AuroraLimitlessActivity:AdminTaskExecutorMain 待機イベント
タスクエグゼキュタープロセスのメインループで待機しています。
## AuroraLimitlessActivity:AdminTaskMonitorMain 待機イベント
タスクモニタリングプロセスのメインループで待機しています。
## AuroraLimitlessActivity:DatabaseCleanupMonitorMain 待機イベント
データベースクリーンアップモニタリングプロセスのメインループで待機しています。
## AuroraLimitlessActivity:TopologyCleanupMonitorMain 待機イベント
トポロジクリーンアップモニタリングプロセスのメインループで待機しています。
## AuroraLimitlessActivity:ToplogyChangeMonitorMain 待機イベント
トポロジ変更モニタリングプロセスのメインループで待機しています。
## AuroraLimitlessActivity:DistributedTransactionMonitorMain 待機イベント
分散トランザクションモニタリングプロセスのメインループで待機しています。
## AuroraLimitlessActivity:GlobalVacuumMonitorMain 待機イベント
グローバルバキュームモニタリングプロセスのメインループで待機しています。
# 関数を使用した効率向上の構築
ユーザー定義関数は、デフォルトでは単一シャードの最適化は行われませんが、シングルシャードオペレーションとして実行するように設定できます。関数はロジックをカプセル化し、単一シャードの最適化方式で実行できます。
## 単一シャードオペレーションが重要な理由
リソース使用率は、パフォーマンスとコスト効率にとって重要です。単一シャードオペレーションでは、クロスシャードオペレーションに比べてリソースの使用が大幅に少なくなります。例えば、関数を実行して 100 万行を挿入する場合、単一シャード実行では約 90.5 ACU、クロスシャード実行では 126.5 ACU が使用されるため、リソース効率が 35% 向上します。
単一シャード実行では、以下も提供されます。
+ クロスシャードオペレーションよりもスループットが 35% 高い
+ より予測可能な応答時間
+ データの増加に伴うスケーラビリティの向上
## シングルシャードオペレーションと関数
関数は、次のいずれかの前提条件が満たされるとシャードで実行されます。
+ 関数はイミュータブルとして作成され、単一シャード最適化クエリに含まれます。
+ 関数はユーザーによって配布されます
シャードで実行される関数は、データがある場所で実行されるため、パフォーマンスとスケーリングが向上します。
## 関数とボラティリティ
関数のボラティリティを確認するには、PostgreSQL のシステムテーブルで次のクエリを使用します。
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
出力例:
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
この例で、`md5()` はイミュータブルで、`random()` は変動します。つまり、`md5()` を含む単一シャード最適化ステートメントは単一シャード最適化のままですが、`random()` を含むステートメントは最適化されません。
イミュータブル関数の例:
```
EXPLAIN ANALYZE
SELECT pg_catalog.md5('123')
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
----------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=3.409..3.409 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.313 ms
Execution Time: 4.253 ms
(4 rows)
```
変動性のある関数の例:
```
EXPLAIN ANALYZE
SELECT pg_catalog.random()
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
------------------------------------------------------
Foreign Scan on t1_fs00001 t1
(cost=100.00..15905.15 rows=1 width=8)
(actual time=0.658..0.658 rows=1 loops=1)
Planning Time: 0.263 ms
Execution Time: 2.892 ms
(3 rows)
```
出力は、`md5()` がプッシュダウンされて、単一シャード最適化として実行されていますが、`random()` はそうではないことを示しています。
## 関数の配布
1 つのシャードのみのデータにアクセスする関数は、パフォーマンス上の利点を得るために、そのシャードで実行する必要があります。関数を分散し、関数の署名に完全なシャードキーを含める必要があります。シャードキーのすべての列をパラメータとして関数に渡す必要があります。
関数の例
```
CREATE OR REPLACE FUNCTION s1.func1(
param_a bigint,
param_b bigint,
param_c char(100)
)
RETURNS int AS $$
DECLARE
res int;
BEGIN
SELECT COUNT(*) INTO res
FROM s1.t1
WHERE s1.t1.col_a = param_a
AND s1.t1.col_b = param_b
AND s1.t1.col_c = param_c;
RETURN res;
END
$$ LANGUAGE plpgsql;
```
ディストリビューションの前は、関数の単一シャードの最適化は行われません。
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=37.503..37.503 rows=1 loops=1)
Planning Time: 0.901 ms
Execution Time: 51.647 ms
(3 rows)
```
関数を配布するには
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
ディストリビューションの後、関数の単一シャードの最適化が行われます。
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.332..4.333 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.857 ms
Execution Time: 5.116 ms
(4 rows)
```
`rds_aurora.limitless_stat_statements` の `sso_calls` 列を確認することで、単一シャードの最適化を確認できます。
```
subcluster_id | subcluster_type | calls | sso_calls | query
--------------+-----------------+-------+-----------+--------------------------------------
2 | router | 2 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
3 | router | 1 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
(2 rows)
```
## 関数と効率のパターン
データの近くでロジックを実行する方が効率的であり、これを実現するには関数が重要な役割を果たします。関数の効率を向上させるには、主に 2 つのユースケースがあります。
1. 複雑なデータからシャードキーを抽出して別の単一シャード最適化関数を呼び出す
1. クロスシャードロジックを単一シャード最適化ステートメントから分離して、クロスシャードワークロードを単一シャード最適化に変換する
### 複雑なデータからシャードキーを抽出する
いくつかのデータベースオペレーションを実行する署名 `s3.func3(p_json_doc json)` を持つ関数について検討します。これらのオペレーションは、すべてのシャードにまたがるトランザクション内のすべてのシャードで実行されます。JSON ドキュメントにシャードキーが含まれている場合、単一シャード最適化関数を構築してデータベースオペレーションを実行できます。
元のパターン:
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
最適化パターン:
```
s3.func3(p_json_doc json)
DECLARE
v_a bigint;
BEGIN
v_a := (p_json_doc->>'field_a')::bigint;
SELECT s3.func3_INNER(v_a, p_json_doc);
END;
```
内部関数は次を実行します。
```
s3.func3_INNER(p_a, p_json_doc)
database operation 1 WHERE shard_key = p_a;
database operation 2 WHERE shard_key = p_a;
database operation 3 WHERE shard_key = p_a;
```
このパターンでは、シャードキーは複雑なデータ型にカプセル化されるか、他のパラメータから推定されます。ロジック、データアクセス、関数は、シャードキーを決定、抽出、または構築し、単一シャードのみに関するオペレーションを実行する単一シャード最適化関数を呼び出すことができます。アプリケーションインターフェイスは変更されないため、最適化のテストは比較的簡単です。
### 他の関数またはデータからのシャードキーの遅延
ロジックまたはデータアクセスがシャードキーを計算または決定する場合、別の設計パターンが適用されます。これは、ほとんどの呼び出しで関数を単一のシャードで実行できますが、クロスシャード実行が必要になる場合があります。
元のパターン:
```
NEWORD(INTEGER, …) RETURNS NUMERIC
DECLARE
all_whid_local := true;
LOOP through the order lines
Generate warehouse ID;
IF generated warehouse ID == input warehouse ID
THEN
ol_supply_whid := input warehouse ID;
ELSE
all_whid_local := false;
ol_supply_whid := generated warehouse ID;
END IF;
…
END LOOP;
…
RETURN no_s_quantity;
```
個別の関数で最適化されたパターン:
```
CREATE OR REPLACE FUNCTION NEWORD_sso(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
SELECT rds_aurora.limitless_distribute_function(
'NEWORD_sso(int,…)',
ARRAY['no_w_id'],
'warehouse'
);
CREATE OR REPLACE FUNCTION NEWORD_crosshard(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
```
次に、メイン関数で単一シャード最適化バージョンまたはクロスシャードバージョンを呼び出します。
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
このアプローチにより、ほとんどの呼び出しは、クロスシャード実行を必要とするケースで正しい動作を維持しながら、単一シャード最適化の恩恵を受けることができます。
## 単一シャードオペレーションの確認
`EXPLAIN` を使用して、ステートメントが単一シャード最適化されているかどうかを確認します。出力は、最適化されたオペレーションの「単一シャードの最適化」を明示的にレポートします。
ディストリビューション前のクロスシャード呼び出し:
```
QUERY PLAN
---------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=59.622..59.623 rows=1 loops=1)
Planning Time: 0.925 ms
Execution Time: 60.211 ms
```
ディストリビューション後の単一シャード呼び出し:
```
QUERY PLAN
----------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.576..4.577 rows=1 loops=1)
Single Shard Optimized
Planning Time: 1.483 ms
Execution Time: 5.404 ms
```
実行時間の違いは、単一シャード最適化のパフォーマンス上の利点を示しています。