本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 監控 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 保護監控 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`：Aurora 容量單位 (ACU) 使用量，以百分比計算 (透過將 `DBShardGroupCapacity` 除以 `DBShardGroupMaxACU`)。 + `DBShardGroupCapacity`：資料庫碎片群組的寫入器執行個體所耗用的 ACU 數量。 + `DBShardGroupComputeRedundancyCapacity`：資料庫碎片群組的待命執行個體所耗用的 ACU 數量。 + `DBShardGroupMaxACU`：資料庫碎片群組設定的 ACU 數目上限。 + `DBShardGroupMinACU`：資料庫碎片群組所需的 ACU 數目下限。 `DBShardGroupIdentifier` 維度索引鍵可用於彙總 `DBShardGroup` 指標。 ## DBShardGroupRouterAggregation 指標 若要在 CloudWatch 主控台中查看 Aurora PostgreSQL Limitless Database 的 `DBShardGroupRouterAggregation` 指標，請選擇 **RDS**，然後選擇 **DBShardGroupRouterAggregation**。 您可以追蹤下列 CloudWatch 指標： + `CommitThroughput`：資料庫碎片群組中所有路由器節點的每秒遞交操作平均數量。 + `DatabaseConnections`：資料庫碎片群組中所有路由器節點的所有連線總和。 ## DBShardGroupInstance 指標 DBShardGroupInstance 是每個碎片或路由器子叢集中的個別資料庫執行個體。 若要在 CloudWatch 主控台中查看 Aurora PostgreSQL Limitless Database 的 `DBShardGroupInstance` 指標，請選擇 **RDS**，然後選擇 **DBShardGroupInstance**。 您可以追蹤下列 CloudWatch 指標： + `ACUUtilization`：以 `ServerlessDatabaseCapacity` 指標除以子叢集的指派 ACU 值上限所計算的百分比。 + `AuroraReplicaLag`：對於啟用運算備援的無限叢集，這是從子叢集中主要執行個體複寫更新時的延遲量。 + `AuroraReplicaLagMaximum`：對於啟用運算備援的無限叢集，這是從子叢集中主要執行個體複寫更新時的最大延遲量。刪除或重新命名僅供讀取複本時，當舊資源經過回收時，複寫延遲可能會暫時遽增。使用此指標，來尋找是否因其中一個讀取器的高複寫延遲而導致容錯移轉。 + `AuroraReplicaLagMinimum`：對於啟用運算備援的無限叢集，這是從子叢集中主要執行個體複寫更新時的最小延遲量。 + `BufferCacheHitRatio`：從執行個體記憶體快取提供的資料和索引百分比 (相對於儲存磁碟區)。 + `CommitLatency`：引擎和儲存體完成特定節點 (路由器或碎片) 遞交操作的平均持續時間。 + `CommitThroughput`：遞交操作的每秒平均數量。 + `CPUUtilization`：CPU 使用量佔子叢集最大指派 ACU 值的百分比。 + `FreeableMemory`：當碎片群組擴展至其最大容量時，可用的未使用記憶體量。這取決於碎片群組的指派 ACU。若為目前容量低於最大容量的每個 ACU，此值增加約 2 GiB。因此，在資料庫碎片群組擴展至上限之前，此指標不會接近零。 + `MaximumUsedTransactionIDs`：最舊的未清理交易 ID 的存留期 (以交易為單位)。如果此值達到 2,146,483,648 (2^31 - 1,000,000)，資料庫將強制進入唯讀模式，以避免交易 ID 包圍。如需詳細資訊，請參閱 PostgreSQL 文件中的[避免交易 ID 包圍失敗](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)。 + `NetworkReceiveThroughput`：資料庫碎片群組中的各個執行個體從用戶端接收到的網路輸送量。此輸送量不包含資料庫碎片群組中的執行個體與叢集磁碟區之間的網路流量。 + `NetworkThroughput`：資料庫碎片群組中用戶端和路由器，以及路由器和碎片之間的彙總網路輸送量 (傳輸和接收)。此輸送量不包含資料庫碎片群組中的執行個體與叢集磁碟區之間的網路流量。 + `NetworkTransmitThroughput`：資料庫碎片群組中的各個執行個體傳送至用戶端的網路輸送量。此輸送量不包含資料庫碎片群組中的執行個體與叢集磁碟區之間的網路流量。 + `ReadIOPS`：磁碟讀取每秒讀寫次數 (IOPS) 的平均次數。 + `ReadLatency`：每次磁碟讀取輸入/輸出 (I/O) 操作耗用的時間。 + `ReadThroughput`：平均每秒從磁碟讀取的位元組數目。 + `ServerlessDatabaseCapacity`：資料庫碎片群組中資料庫碎片或路由器子叢集的目前容量。 + `StorageNetworkReceiveThroughput`：資料庫碎片群組中各個執行個體從 Aurora 儲存子系統接收到的網路輸送量。 + `StorageNetworkThroughput`：資料庫碎片群組中每個執行個體從 Aurora 儲存子系統傳輸和接收的彙總網路輸送量。 + `StorageNetworkTransmitThroughput`：資料庫碎片群組中各個執行個體傳送至 Aurora 儲存子系統的網路輸送量。 + `SwapUsage`：資料庫碎片群組使用的交換空間量。 + `TempStorageIOPS`：在連接至資料庫執行個體的本機儲存體上執行的 I/O 操作平均數量。其中包含讀取和寫入 I/O 操作。 `TempStorageIOPS` 可與 `TempStorageThroughput` 搭配使用，以診斷於資料庫執行個體和本機儲存體間進行傳輸之網路活動造成容量意外增加的罕見狀況。 + `TempStorageThroughput`：傳入和傳出與路由器或碎片相關聯之本機儲存體的資料量。 + `WriteIOPS`：磁碟寫入 IOPS 的平均數量。 + `WriteLatency`：平均每次磁碟寫入輸入/輸出操作耗用的時間。 + `WriteThroughput`：平均每秒寫入磁碟的位元組數目。 下列維度金鑰可用於彙總 `DBShardGroupInstance` 指標： + `DBClusterIdentifier`：Aurora PostgreSQL 資料庫叢集。 + `DBShardGroupIdentifier`：執行個體所屬的資料庫碎片群組。 + `DBShardGroupSubClusterType`：節點類型，可以是 `Distributed Transaction Router` (路由器) 或 `Data Access Shard` (碎片)。 + `DBShardGroupSubClusterIdentifier`：執行個體所屬的路由器或碎片名稱。 以下是彙總 CloudWatch 指標的範例： + 資料庫碎片群組中屬於特定碎片或路由器的所有執行個體總計 `CPUUtilization`。 + 資料庫碎片群組中所有執行個體的總計 `CPUUtilization`。 ## DBClusterIdentifier 指標 若要在 CloudWatch 主控台查看 Aurora PostgreSQL Limitless Database 的 `DBClusterIdentifier` 指標，請選擇 **RDS**，然後選擇 **DBClusterIdentifier**。 當您使用 Aurora PostgreSQL Limitless Database 時，可能會有比 Aurora 資料庫叢集更多的輸入/輸出 (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，為所有 I/O 操作支付單一每月價格，而不是為每一百萬個 I/O 請求付費。如需更多詳細資訊，請參閱 [Amazon Aurora 資料庫叢集的儲存組態](Aurora.Overview.StorageReliability.md#aurora-storage-type)。 您也可以使用比 Aurora 資料庫叢集更多的儲存空間。您可以追蹤下列 CloudWatch 儲存指標： + `BackupRetentionPeriodStorageUsed`：Aurora PostgreSQL Limitless Database 叢集的計費連續備份儲存使用量總計。 + `SnapshotStorageUsed`：Aurora PostgreSQL Limitless Database 叢集的計費快照儲存使用量總計。 + `TotalBackupStorageBilled`：自動備份保留和資料庫叢集快照的成本總和。 如需備份儲存成本的詳細資訊，請參閱[了解 Amazon Aurora 備份儲存體用量](aurora-storage-backup.md)。 + `VolumeBytesUsed`：Aurora PostgreSQL Limitless Database 叢集使用的儲存量，每隔 5 分鐘回報一次。 # 使用 CloudWatch Database Insights 監控 Aurora PostgreSQL Limitless Database 啟用 Aurora PostgreSQL Limitless Database 時，需要 Database Insights 的標準模式。您可以使用此模式，來即時監控 Limitless Database 資料庫執行個體的資料庫負載 (資料庫負載)。資料庫負載會測量資料庫中工作階段活動的層級。您可以使用 Database Insights，大規模分析 Aurora PostgreSQL Limitless Database 資料庫執行個體的效能和進行疑難排解。 如需 CloudWatch Database Insights 的詳細資訊，請參閱下列主題。 + [使用 CloudWatch Database Insights 監控 Amazon Aurora 資料庫](USER_DatabaseInsights.md) + [Amazon CloudWatch 使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html)中的 *CloudWatch Database Insights* + *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 建立資料庫叢集時，開啟 Database Insights 的進階模式 為 Aurora PostgreSQL Limitless Database 建立資料庫時，開啟 Database Insights 的進階模式。 ------ #### [ Console ] 在此主控台中，您可以在建立資料庫叢集時開啟 Database Insights 的進階模式。Database Insights 的設定適用於資料庫叢集中的所有資料庫執行個體。 **使用主控台建立資料庫叢集時，開啟 Database Insights 的進階模式** 1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 選擇 **Databases** (資料庫)。 1. 選擇**建立資料庫**。 1. 在 **Database Insights** 區段中，選取**進階模式**。然後選擇下列選項： + **Retention (保留)** – 保留 Performance Insights 資料的時間。Database Insights 進階模式的保留期間必須為 15-24 個月。 + **AWS KMS key** – 指定您的 KMS 金鑰。績效詳情使用您的 KMS 金鑰來加密所有可能的敏感資料。將會對傳輸中與靜態資料進行加密。如需更多詳細資訊，請參閱 [加密 Amazon Aurora 資源](Overview.Encryption.md)。 1. 選擇**建立資料庫**。 ------ #### [ AWS CLI ] 若要在建立資料庫叢集時開啟 Database Insights 的進階模式，請呼叫 [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI 命令並提供下列值： + `--db-cluster-identifier`：資料庫叢集的識別符。 + `--database-insights-mode advanced` 以開啟 Database Insights 的進階模式。 + `--engine`：資料庫叢集必須使用 `aurora-postgresql` 資料庫引擎。 + `--engine-version`：資料庫叢集必須使用其中一個資料庫引擎版本： + `16.4-limitless` + `16.6-limitless` + `--storage-type`：資料庫叢集必須使用 `aurora-iopt1` 資料庫叢集儲存組態。 + `--cluster-scalability-type`：指定 Aurora 資料庫叢集的可擴展性模式。設為 `limitless` 時，叢集會以 Aurora PostgreSQL Limitless Database 的形式運作。設為 `standard` (預設值) 時，叢集會使用一般資料庫執行個體建立。 **注意** 您無法在建立資料庫叢集之後修改此設定。 + `--master-username`：資料庫叢集主要使用者的名稱。 + `--master-user-password`：主要使用者密碼。 + `--enable-performance-insights` 以開啟 Database Insights 的 Performance Insights。 + `--performance-insights-retention-period`：資料庫叢集資料的保留期間。若要開啟 Database Insights ，保留期必須至少為 465 天。 + `--monitoring-interval`：為資料庫叢集收集增強型監控指標點之間的間隔 (秒)。此值不能是 `0`。 + `--monitoring-role-arn`：允許 RDS 將增強型監控指標傳送到 Amazon CloudWatch Logs 之 IAM 角色的 Amazon Resource Name (ARN)。 + `--enable-cloudwatch-logs-exports`：您必須將 `postgresql` 日誌匯出至 CloudWatch Logs。 下列範例會在建立資料庫叢集時啟用 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 ] 若要在建立資料庫叢集時開啟 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 Resource Name (ARN) ------ ## 為 Aurora PostgreSQL Limitless Database 修改資料庫叢集時，開啟 Database Insights 的進階模式 為 Aurora PostgreSQL Limitless Database 修改資料庫時，開啟 Database Insights。 **注意** 若要啟用 Database Insights ，資料庫叢集中每個資料庫執行個體都必須具有相同的 Performance Insights 和增強型監控設定。 ------ #### [ Console ] 在主控台中，您可以在修改資料庫叢集時開啟 Database Insights 的進階模式。Database Insights 的設定適用於資料庫叢集中的所有資料庫執行個體。 **使用主控台修改資料庫叢集時，開啟 Database Insights 的進階模式** 1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 選擇 **Databases** (資料庫)。 1. 選擇資料庫叢集，然後選擇**修改**。 1. 在 **Database Insights** 區段中，選取**進階模式**。然後選擇下列選項： + **Retention (保留)** – 保留 Performance Insights 資料的時間。Database Insights 進階模式的保留期間必須為 15-24 個月。 + **AWS KMS key** – 指定您的 KMS 金鑰。績效詳情使用您的 KMS 金鑰來加密所有可能的敏感資料。將會對傳輸中與靜態資料進行加密。如需更多詳細資訊，請參閱 [加密 Amazon Aurora 資源](Overview.Encryption.md)。 1. 選擇 **Continue** (繼續)。 1. 在 **Scheduling of Modifications (修改排程)** 中，選擇 **Apply immediately (立即套用)**。如果您選擇**在下一個排定的維護時段套用**，則資料庫會忽略此設定，並立即開啟 Database Insights 的進階模式。 1. 選擇**修改叢集**。 ------ #### [ AWS CLI ] 若要在修改資料庫叢集時開啟 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`：資料庫叢集的識別符。 + `--enable-performance-insights` 以開啟 Database Insights 的 Performance Insights。 + `--performance-insights-retention-period`：資料庫叢集的資料保留期間。若要開啟 Database Insights 的進階模式，保留期必須至少為 465 天。 下列範例會在修改資料庫叢集時啟用 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 ] 若要在修改資料庫叢集時開啟 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 建立資料庫叢集時，開啟 Database Insights 的標準模式 為 Aurora PostgreSQL Limitless Database 建立資料庫時，開啟 Database Insights 的標準模式。 ------ #### [ Console ] 在此主控台中，您可以在建立資料庫叢集時開啟 Database Insights 的標準模式。Database Insights 的設定適用於資料庫叢集中的所有資料庫執行個體。 **使用主控台建立資料庫叢集時，開啟 Database Insights 的標準模式** 1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 選擇 **Databases** (資料庫)。 1. 選擇**建立資料庫**。 1. 在 **Database Insights** 區段中，選取**標準模式**。然後選擇下列選項： + **Retention (保留)** – 保留績效詳情資料的時間。若要為 Aurora PostgreSQL Limitless Database 建立資料庫叢集，保留期間必須至少為 31 天。 + **AWS KMS key** – 指定您的 KMS 金鑰。績效詳情使用您的 KMS 金鑰來加密所有可能的敏感資料。將會對傳輸中與靜態資料進行加密。如需更多詳細資訊，請參閱 [加密 Amazon Aurora 資源](Overview.Encryption.md)。 1. 選擇**建立資料庫**。 ------ #### [ AWS CLI ] 若要在建立資料庫叢集時開啟 Database Insights 的標準模式，請呼叫 [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI 命令並提供下列值： + `--db-cluster-identifier`：資料庫叢集的識別符。 + `--database-insights-mode standard` 以開啟 Database Insights 的標準模式。 + `--engine`：資料庫叢集必須使用 `aurora-postgresql` 資料庫引擎。 + `--engine-version`：資料庫叢集必須使用其中一個資料庫引擎版本： + `16.4-limitless` + `16.6-limitless` + `--storage-type`：資料庫叢集必須使用 `aurora-iopt1` 資料庫叢集儲存組態。 + `--cluster-scalability-type`：指定 Aurora 資料庫叢集的可擴展性模式。設為 `limitless` 時，叢集會以 Aurora PostgreSQL Limitless Database 的形式運作。設為 `standard` (預設值) 時，叢集會使用一般資料庫執行個體建立。 **注意** 您無法在建立資料庫叢集之後修改此設定。 + `--master-username`：資料庫叢集主要使用者的名稱。 + `--master-user-password`：主要使用者密碼。 + `--enable-performance-insights` 以開啟 Database Insights 的 Performance Insights。 + `--performance-insights-retention-period`：資料庫叢集資料的保留期間。若要為 Aurora PostgreSQL Limitless Database 建立資料庫叢集，保留期間必須至少為 31 天。 + `--monitoring-interval`：為資料庫叢集收集增強型監控指標點之間的間隔 (秒)。此值不能是 `0`。 + `--monitoring-role-arn`：允許 RDS 將增強型監控指標傳送到 Amazon CloudWatch Logs 之 IAM 角色的 Amazon Resource Name (ARN)。 + `--enable-cloudwatch-logs-exports`：您必須將 `postgresql` 日誌匯出至 CloudWatch Logs。 下列範例會在建立資料庫叢集時啟用 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 ] 若要在建立資料庫叢集時開啟 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 Resource Name (ARN) ------ ## 為 Aurora PostgreSQL Limitless Database 修改資料庫叢集時，開啟 Database Insights 的標準模式 為 Aurora PostgreSQL Limitless Database 修改資料庫時，開啟 Database Insights。 **注意** 若要啟用 Database Insights，資料庫叢集中的每個資料庫執行個體都必須具有相同的 Performance Insights 和增強型監控設定。 ------ #### [ Console ] 在此主控台中，您可以在建立資料庫叢集時開啟 Database Insights 的標準模式。Database Insights 的設定適用於資料庫叢集中的所有資料庫執行個體。 **使用主控台修改資料庫叢集時，開啟 Database Insights 的標準模式** 1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 選擇 **Databases** (資料庫)。 1. 選擇資料庫叢集，然後選擇**修改**。 1. 在 **Database Insights** 區段中，選取**標準模式**。然後選擇下列選項： + **Retention (保留)** – 保留 Performance Insights 資料的時間。若要為 Aurora PostgreSQL Limitless Database 建立資料庫叢集，保留期間必須至少為 31 天。 + **AWS KMS key** – 指定您的 KMS 金鑰。績效詳情使用您的 KMS 金鑰來加密所有可能的敏感資料。將會對傳輸中與靜態資料進行加密。如需更多詳細資訊，請參閱 [加密 Amazon Aurora 資源](Overview.Encryption.md)。 1. 選擇 **Continue** (繼續)。 1. 在 **Scheduling of Modifications (修改排程)** 中，選擇 **Apply immediately (立即套用)**。如果您選擇**在下一個排定的維護時段套用**，則資料庫會忽略此設定，並立即開啟 Database Insights 的標準模式。 1. 選擇**修改叢集**。 ------ #### [ AWS CLI ] 若要在修改資料庫叢集時開啟 Database Insights 的標準模式，請呼叫 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 命令並提供下列值： + `--db-cluster-identifier`：資料庫叢集的識別符。 + `--database-insights-mode standard` 以開啟 Database Insights 的標準模式。 + `--enable-performance-insights` 以開啟 Database Insights 的 Performance Insights。 + `--performance-insights-retention-period`：資料庫叢集資料的保留期間。若要開啟 Database Insights 的標準模式，保留期必須至少為 31 天。 下列範例會在修改資料庫叢集時啟用 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 ] 若要在修改資料庫叢集時開啟 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。您可以在 CloudWatch Logs Insights 中存取和分析這些日誌，類似於存取標準 Aurora PostgreSQL 資料庫叢集的 PostgreSQL 日誌。如需更多詳細資訊，請參閱 [使用 CloudWatch Logs Insights 分析 PostgreSQL 日誌](AuroraPostgreSQL.CloudWatch.Analyzing.md)。 資料庫叢集的日誌群組名稱與 Aurora PostgreSQL 中的名稱相同： ``` /aws/rds/cluster/DB_cluster_ID/postgresql ``` 資料庫碎片群組的日誌群組名稱採用下列形式： ``` /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` **注意** 您無法如在資料庫叢集所做一樣，直接在 RDS 主控台、AWS CLI 或 RDS API 中檢視資料庫碎片群組的 PostgreSQL 日誌檔案。您必須使用 CloudWatch Logs Insights 來檢視這些檔案。 # 使用增強型監控來監控 Aurora PostgreSQL Limitless Database 啟用 Aurora PostgreSQL Limitless Database 時需要增強型監控。您可以使用此功能來即時監控 Limitless Database 資料庫執行個體的作業系統。 Aurora 在 CloudWatch Logs 中發佈增強型監控指標。一些可用的關鍵指標包括資料庫連線、儲存空間用量和查詢延遲。這些指標可協助判斷效能瓶頸。 如需增強式監控指標的詳細資訊，請參閱 [Aurora​ 的作業系統指標](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 資料庫叢集的運作方式類似。不過，您可以在 Aurora PostgreSQL Limitless Database 的碎片群組層級追蹤指標。 要追蹤的兩個主要 Performance Insights 指標如下： + 資料庫負載：測量資料庫中的活動程度。績效詳情中的關鍵指標為 `DBLoad`，每秒收集一次。 Performance Insights 中 `DBLoad` 指標的單位是平均作用中工作階段 (AAS)。為了取得平均作用中工作階段，績效詳情會取樣並行執行查詢的工作階段數目。AAS 是將特定時段內的工作階段總數除以樣本總數。如需 `DBLoad` 和 AAS 的詳細資訊，請參閱[資料庫負載](USER_PerfInsights.Overview.ActiveSessions.md)。 + CPU 上限：資料庫可用的運算能力上限。若要查看作用中的工作階段是否超過最大 CPU，請查看其與 `Max vCPU` 數線的關係。`Max vCPU` 數值由資料庫執行個體的 vCPU (虛擬 CPU) 核心數目決定。如需 `Max vCPU` 的詳細資訊，請參閱[最大 CPU](USER_PerfInsights.Overview.MaxCPU.md)。 此外，您可以將 `DBLoad` 指標「分割」為*維度*，這是指標的子類別。最有用的維度如下： + 熱門執行個體：以遞減順序顯示執行個體 (碎片和路由器) 的相對資料庫負載。 + 等待事件：導致 SQL 陳述式等待特定事件發生後，才能繼續執行。等待事件指出工作受阻的位置。 + 熱門 SQL：顯示哪些查詢對資料庫負載的貢獻最多。 如需 Performance Insights 維度的詳細資訊，請參閱[維度](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions)。 下圖顯示資料庫碎片群組的**熱門執行個體**維度。 ![\[資料庫碎片群組的熱門執行個體維度。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) **Topics** + [使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的資料庫負載](USER_PerfInsights.AnalyzeLimitlessTables.md) # 使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的資料庫負載 使用 Performance Insights，您可以在碎片群組層級和執行個體層級追蹤 Aurora PostgreSQL Limitless Database 的指標。分析 Aurora PostgreSQL Limitless Database 的資料庫負載時，建議您將每個碎片和路由器的資料庫負載與最大 vCPU 進行比較。 **注意** Aurora PostgreSQL Limitless Database 一律啟用 Performance Insights 和增強型監控。Limitless Database 的 Performance Insights 資料的最短保留期間為 31 天 (1 個月)。 **絕對**檢視會顯示平均作用中工作階段 (AAS) 的數量和預估 vCPU。**相對**檢視會顯示 AAS 與預估 vCPU 的比率。 **Topics** + [使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的相對資料庫負載](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad) + [使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的按等待資料庫負載](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md) + [使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的負載分配](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md) ## 使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的相對資料庫負載 您可能想要透過追蹤相對資料庫負載，改善 Aurora PostgreSQL Limitless Database 的效能。若要按執行個體來分析 Aurora PostgreSQL Limitless Database 的相對資料庫負載，請使用下列程序。 **使用主控台分析 Aurora PostgreSQL Limitless Database 的相對資料庫負載** 1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。 1. 選擇 Aurora PostgreSQL Limitless Database。Performance Insights 儀表板會針對該 Aurora PostgreSQL Limitless Database 顯示。 1. 在**資料庫負載**區段中，選擇**配量依據**旁邊的**執行個體**。若要查看 Aurora PostgreSQL Limitless Database 中所有執行個體的平均作用中工作階段 (AAS) 與 vCPU 核心的比率，請針對**檢視為**選擇**相對**。 平均作用中工作階段圖表顯示 Aurora PostgreSQL Limitless Database 中執行個體的資料庫負載。 ![\[檢視 Performance Insights 儀表板以取得按執行個體配量的 Aurora PostgreSQL Limitless Database。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png) 1. 若要檢視熱門執行個體，請選擇**熱門執行個體**索引標籤。 在下列範例中，資料庫負載最高的執行個體為 `DTR-2-2`。 ![\[針對按執行個體配量的 Aurora PostgreSQL Limitless Database，使用 [熱門執行個體] 索引標籤。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) 1. (選用) 若要分析 Aurora PostgreSQL Limitless Database 中執行個體的資料庫負載，請在**執行個體**欄中選擇執行個體名稱。若要檢視 `DTR-2-2` 的資料庫負載，請在**執行個體**欄中選擇 `DTR-2-2`。 **注意** 您只能針對 Aurora PostgreSQL Limitless Database 中的執行個體檢視 Performance Insights 指標。 # 使用 Performance Insights 儀表板分析 Aurora PostgreSQL Limitless Database 的按等待資料庫負載 您可能想要透過追蹤等待事件，改善 Aurora PostgreSQL Limitless Database 的效能。若要按等待事件來分析 Aurora PostgreSQL Limitless Database 的資料庫負載，請使用下列程序。 **使用主控台按等待分析 Aurora PostgreSQL Limitless Database 的資料庫負載** 1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。 1. 選擇 Aurora PostgreSQL Limitless Database。Performance Insights 儀表板會針對該 Aurora PostgreSQL Limitless Database 顯示。 1. 在**資料庫負載**區段中，針對**配量依據**選擇**等待**。若要檢視 AAS 的數量和估計 vCPU，請針對**檢視為**選擇**絕對**。 平均作用中工作階段圖表顯示 Aurora PostgreSQL Limitless Database 中執行個體的資料庫負載。 ![\[按等待配量。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png) 1. 向下捲動至 **Top SQL** (最高 SQL) 索引標籤。 在下列範例中，按等待之負載最高的 SQL 陳述式是 `DELETE` 陳述式。 ![\[按等待配量時的最佳 SQL 索引標籤。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png) 1. 選擇 SQL 陳述式，展開到其元件陳述式中。 在下列範例中，`SELECT` 陳述式有 3 個元件陳述式。 ![\[選擇 SQL 陳述式以展開它。\]](http://docs.aws.amazon.com/zh_tw/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. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。 1. 選擇 Aurora PostgreSQL Limitless Database。Performance Insights 儀表板會針對該 Aurora PostgreSQL Limitless Database 顯示。 1. 在**資料庫負載**區段中，選擇**配量依據**旁邊的**執行個體**。若要檢視 Aurora PostgreSQL Limitless Database 中所有執行個體的 AAS 數量和估計 vCPU，請針對**檢視為**選擇**絕對**。 平均作用中工作階段圖表顯示 Aurora PostgreSQL Limitless Database 中執行個體的資料庫負載。 ![\[檢視依執行個體配量之 Aurora PostgreSQL Limitless Database 的絕對 Performance Insights 儀表板。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png) 1. 若要查看 Aurora PostgreSQL Limitless Database 中執行個體負載分配的圖表，請選擇**負載分配**索引標籤。 在下列範例中，資料庫負載最高的執行個體為 `DTR-2-2`。 ![\[當您按執行個體層級等待配量時的最佳 SQL 索引標籤。\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png) # 使用 Amazon GuardDuty RDS 保護監控 Aurora PostgreSQL Limitless Database Amazon GuardDuty 是一種威脅偵測服務，可協助保護您的帳戶、容器、工作負載和 AWS 環境中的資料。GuardDuty 使用機器學習 (ML) 模型，以及異常和威脅偵測功能，持續監控不同的日誌來源和執行時期活動，以識別環境中的潛在安全風險和惡意活動和排定其優先順序。 GuardDuty RDS Protection 會分析和描述登入事件，以找出 Amazon Aurora 資料庫的潛在存取威脅。當您開啟 RDS Protection 時，GuardDuty 會從您的 Aurora 資料庫取用 RDS 登入事件。RDS Protection 會監控這些事件並描述它們，以找出潛在的內部威脅或外部演員。 如需 Aurora 中 GuardDuty RDS 保護的詳細資訊，請參閱[使用 Amazon GuardDuty RDS Protection for Amazon Aurora監控威脅](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 文件中的[函數和運算子](https://www.postgresql.org/docs/15/functions.html)。 **limitless\$1backend\$1dsid** `limitless_backend_dsid` 函數會傳回目前工作階段的分散式工作階段 ID。分散式工作階段會在資料庫碎片群組中的路由器執行，以及涉及資料庫碎片群組中一或多個碎片的後端程序。 下列範例示範如何使用 `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` 函數會傳回資料庫碎片群組中資料庫的大小。 輸入參數如下： + `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` 函數會傳回目前準備進行兩階段遞交之所有節點的交易相關資訊。如需詳細資訊，請參閱 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` 函數會傳回資料庫碎片群組中資料表的不同大小。 輸入參數如下： + `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` 函數會捨棄 `limitless_stat_statements` 目前為止收集的統計資料 (對應於指定的 `username`、`dbname`、`distributed_query_id`和 `queryid` 參數)。如果未指定任何參數，則會針對每個參數使用預設值 `""` 或 `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 文件中的[檢視統計資料](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS)。 **注意** 如果您有進行中的交易，某些統計資料檢視可能會傳回不一致的結果。 **limitless\$1database** 此檢視包含資料庫碎片群組中可用資料庫的相關資訊。例如： ``` 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** 此檢視包含每個節點每個程序一個列。其提供鎖定相關資訊的存取權，該鎖定由資料庫伺服器中作用中程序所保留。 **Example 使用兩個交易建立鎖定** 在此範例中，我們在兩個路由器同時執行兩個交易。 ``` # 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; ``` 執行第一個交易。後續交易必須等到第一個交易完成。因此，系統會使用鎖定封鎖第二個交易。若要檢查其根本原因，我們會透過使用 `limitless_stat_activity` 聯結 `limitless_locks` 來執行命令。 ``` # 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** 此檢視包含每個節點每個程序一個列。其可用於追蹤需要長時間的整體系統運作狀態和分類程序。例如： ``` 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** 此檢視包含資料庫碎片群組中索引的使用量統計資料。例如： ``` 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** 此檢視包含資料庫碎片群組中目前資料庫中所有資料表的統計資料。這在追蹤清空操作和資料處理語言 (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** 此檢視包含資料庫碎片群組中所有資料庫的相關統計資料。每個節點每個資料庫傳回一個列。例如： ``` 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 陳述式的規劃和執行統計資料。 您必須安裝 [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) 延伸模組才能使用 `limitless_stat_statements` 檢視。 ``` -- 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** 此檢視包含路由器和其他節點之間的網路統計資料。其包含每對路由器和其他節點的列，例如： ``` 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)：當內部資料庫請求與始發者路由器位於相同的可用區域時，對此節點的累積請求數量 + `cross_az_requests` (bigint)：當內部資料庫請求與始發者路由器位於不同的可用區域時，對此節點的累積請求數量 + `stat_reset_timestamp` (時間戳記)：此檢視的累積統計資料上次重設時的時間戳記 **limitless\$1statio\$1all\$1indexes** 此檢視包含資料庫碎片群組中所有索引的輸入/輸出 (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** 此檢視包含資料庫碎片群組中所有資料表的輸入/輸出 (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 等待事件 等待在兩階段狀態檔案集區中寫入兩階段狀態檔案。這是 Aurora 特定的事件。 ### 原因 `PREPARED TRANSACTION` 命令的執行程序 (包括 Limitless Database 分散式交易中的參與者)，都必須保留兩階段檔案中的交易狀態。Aurora 使用檔案集區來改善此操作的效能。 ### 動作 這是同步寫入 I/O 操作，因此在此事件中的高延遲具有與 `IO:XactSync` 相似的原因，並且可以以相同的方式接受調查。如果使用 Limitless Database，您可能需要減少執行中的分散式交易數量。 ## IO:TwophaseFilePoolRead 等待事件 等待讀取兩階段狀態檔案集區中的兩階段狀態檔案。 ### 原因 針對先前預備的交易執行 `COMMIT PREPARED` 命令的程序 (包括 Limitless Database 分散式交易的參與者)，都可能需要從兩階段檔案中讀取先前持續的交易狀態。Aurora 使用檔案集區來改善此操作的效能。 ### 動作 這是讀取 I/O 操作。因此，此事件中的高延遲具有與 `IO:DataFileRead` 類似的原因，而且可以以相同的方式接受調查。如果使用 Limitless Database，您可能需要減少執行中的分散式交易數量。 ## AuroraLimitless:Connect 等待事件 程序正在等待與叢集中另一個節點的連線建立完成。 ### 原因 在程序和遠端節點之間建立連線，以執行查詢、分散式交易和執行 DDL。 ### 動作 減少叢集的同時連線數，或調校跨碎片查詢的使用。 ## AuroraLimitless:AsyncConnect 等待事件 此事件類似於 `Connect`，但代表等待與一組節點建立平行連線的程序。 ### 原因 平行連線建立最常在執行 DDL 陳述式時完成。 ### 動作 減少 DDL 陳述式的數量，或在同一工作階段中合併多個 DDL，以改善連線重複使用。 ## AuroraLimitless:RemoteStatementSetup 等待事件 程序正等待遠端查詢執行設定，例如游標開啟、關閉或預備陳述式建立。 ### 原因 此等待事件會隨著碎片資料表上的掃描次數增加，其中陳述式無法進行單一碎片最佳化。 ### 動作 最佳化查詢，以減少掃描操作的次數或提高單一碎片最佳化的資格。 ## AuroraLimitless:RemoteDDLExecution 等待事件 程序正等待遠端 DDL 命令完成。 ### 原因 當您在資料庫碎片群組發出 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 等待事件 程序正在遞交分散式交易，並等待所有參與者確認準備命令。 ### 原因 修改多個節點的交易必須執行分散式遞交。在 `DistributedCommitPrepare` 中長時間等待可能是由於參與節點上 `IO:TwophaseFilePoolWrite` 事件長時間等待所致。 ### 動作 減少交易數量，這些交易會修改多個節點上的資料。調查叢集其他節點中的 `IO:TwophaseFilePoolWrite` 事件。 ## AuroraLimitless:DistributedCommit 等待事件 程序正在遞交分散式交易，並等待主要參與者確認遞交命令。 ### 原因 修改多個節點的交易必須執行分散式遞交。在 `DistributedCommit` 中長時間等待可能是由於主要參與者上 `IO:XactSync` 事件長時間等待所致。 ### 動作 減少交易數量，這些交易會修改多個節點上的資料。調查叢集其他節點中的 `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 等待事件 等待全域清空監控程序的主迴圈。 # 使用 函數建置以提高效率 使用者定義的函數預設不會進行單一碎片最佳化，但可以設定為執行單一碎片操作。函數可以封裝邏輯，並確保以單一碎片最佳化的方式執行。 ## 為什麼單一碎片操作很重要 資源使用率對於效能和成本效益至關重要。相較於跨碎片操作，單一碎片操作使用的資源明顯較少。例如，執行函數以插入一百萬個資料列時，單一碎片執行會使用大約 90.5 ACUs，相較於 126.5 ACUs 進行跨碎片執行，資源效率提升 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()` 則否。 ## 分發 函數 僅在一個碎片上存取資料的函數應該在該碎片上執行，以獲得效能優勢。必須分發函數，且函數簽章必須包含完整的碎片索引鍵 - 碎片索引鍵中的所有資料欄都必須作為參數傳遞至函數。 函數範例： ``` 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) ``` 您可以檢查 中的`sso_calls`資料欄，以確認單一碎片最佳化`rds_aurora.limitless_stat_statements`： ``` 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) ``` ## 函數和效率模式 執行靠近資料的邏輯更有效率，而且函數在達成此目標時扮演重要角色。使用 函數提高效率有兩種主要使用案例： 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 ``` 執行時間的差異顯示了單一碎片最佳化的效能優勢。