# 监控 Aurora PostgreSQL Limitless Database 您可以使用 Amazon CloudWatch、增强监控和性能详情来监控 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-monitoring.cwdbi.md) + [ # 使用 Amazon CloudWatch Logs 监控 Aurora PostgreSQL Limitless Database ](limitless-monitoring.cwl.md) + [ # 使用增强监控指标监控 Aurora PostgreSQL Limitless Database ](limitless-monitoring.em.md) + [ # 使用性能详情监控 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` – 根据 `DBShardGroupCapacity` 除以 `DBShardGroupMaxACU` 计算得出的 Aurora 容量单位（ACU）使用百分比。 + `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 的期限。如果此值达到 2146483648 (2^31 - 1000000)，则强制数据库进入只读模式，避免事务 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` – 每个磁盘读取 I/O 操作所需的平均时间。 + `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 时，您的输入/输出（I/O）操作可能比使用 Aurora 数据库集群还要多。您可以跟踪 Limitless Database 集群的以下 CloudWatch 指标： + `VolumeReadIops` – 每隔 5 分钟报告的集群卷中的计费读取 I/O 操作数量。 + `VolumeWriteIops` – 集群卷的写入磁盘 I/O 操作数，每隔 5 分钟报告一次。 Aurora PostgreSQL Limitless Database 使用 Aurora I/O-Optimized 集群存储配置。使用 Aurora I/O-Optimized，您只需每月为所有（而不是每百万次） 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 无限制数据库 启用 Aurora PostgreSQL 无限制数据库时需要标准模式的 Database Insights。您可以使用该功能来实时监控无限制数据库实例的数据库负载。数据库负载可衡量数据库中会话活动的级别。您可以使用 Database Insights 来大规模分析 Aurora PostgreSQL 无限制数据库实例的性能并排查其故障。 有关 CloudWatch Database Insights 的更多信息，请参阅以下主题。 + [使用 CloudWatch 数据库洞察监控 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 的数据库洞察配置您的数据库以监控慢速 SQL 查询](USER_DatabaseInsights.SlowSQL.md) 有关启用 Database Insights 的高级模式或标准模式的信息，请参阅以下主题。 **Topics** + [ # 为 Aurora PostgreSQL 无限制数据库开启 Database Insights 的高级模式 ](limitless-monitoring.cwdbi.advanced.md) + [ # 为 Aurora PostgreSQL 无限制数据库开启 Database Insights 的标准模式 ](limitless-monitoring.cwdbi.standard.md) # 为 Aurora PostgreSQL 无限制数据库开启 Database Insights 的高级模式 要为 Aurora PostgreSQL 无限制数据库开启 Database Insights 的高级模式，请按照以下过程操作。 ## 为 Aurora PostgreSQL 无限制数据库创建数据库集群时开启 Database Insights 的高级模式 为 Aurora PostgreSQL 无限制数据库创建数据库时启用 Database Insights 的高级模式。 ------ #### [ Console ] 在控制台中，您可以在创建数据库集群时开启数据库洞察的高级模式。数据库洞察的设置适用于数据库集群中的所有数据库实例。 **在使用控制台创建数据库集群时，开启 Database Insights 的高级模式** 1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。 1. 选择**数据库**。 1. 选择**创建数据库**。 1. 在**数据库洞察**部分，选择**高级模式**。然后，选择以下选项： + **保留** – 保留性能详情数据的时间。对于数据库洞察的高级模式，保留期必须为 15-24 个月。 + **AWS KMS key** - 指定您的 KMS 密钥。性能详情使用您的 KMS 密钥来加密所有潜在的敏感数据。正在传输的数据和静态数据都会被加密。有关更多信息，请参阅 [加密 Amazon Aurora 资源](Overview.Encryption.md)。 1. 选择**创建数据库**。 ------ #### [ AWS CLI ] 要在创建数据库集群时开启数据库洞察的高级模式，请调用 [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`，开启数据库洞察的高级模式。 + `--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`，开启数据库洞察的性能详情。 + `--performance-insights-retention-period` – 数据库集群数据的保留期。要开启数据库洞察，保留期必须至少为 465 天。 + `--monitoring-interval` – 收集数据库集群的增强监控指标的时间点之间的间隔，以秒为单位。该值不能为 `0`。 + `--monitoring-role-arn` – 允许 RDS 将增强监控指标发送到 Amazon CloudWatch Logs 的 IAM 角色的 Amazon 资源名称（ARN）。 + `--enable-cloudwatch-logs-exports` – 您必须将 `postgresql` 日志导出到 CloudWatch 日志。 以下示例在创建数据库集群时启用数据库洞察的高级模式。 对于 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 ] 要在创建数据库集群时开启数据库洞察的高级模式，请为 [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API 操作指定以下参数。 + `DatabaseInsightsMode` 到 `advanced` + `Engine` 到 `aurora-postgresql` + `EngineVersion` 设置为无限制数据库的可用引擎版本 + `StorageType` 到 `aurora-iopt1` + `ClusterScalabilityType` 到 `limitless` + `MasterUsername` + `MasterUserPassword` + `EnablePerformanceInsights` 到 `True` + `PerformanceInsightsRetentionPeriod` 设置为至少 `465` 天 + `MonitoringInterval` 设置为非 `0` 的值 + `MonitoringRoleArn` 设置为 IAM 角色的 Amazon 资源名称（ARN），该角色应可以让 RDS 将增强监控指标发送到 Amazon CloudWatch Logs。 ------ ## 为 Aurora PostgreSQL 无限制数据库修改数据库集群时开启 Database Insights 的高级模式 为 Aurora PostgreSQL 无限制数据库修改数据库时开启 Database Insights。 **注意** 要启用 Database Insights，数据库集群中的每个数据库实例都必须具有相同的性能详情和增强监控设置。 ------ #### [ Console ] 在控制台中，您可以在修改数据库集群时开启数据库洞察的高级模式。数据库洞察的设置适用于数据库集群中的所有数据库实例。 **在使用控制台修改数据库集群时，开启 Database Insights 的高级模式** 1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。 1. 选择**数据库**。 1. 选择数据库集群，然后选择**修改**。 1. 在**数据库洞察**部分，选择**高级模式**。然后，选择以下选项： + **保留** – 保留性能详情数据的时间。对于数据库洞察的高级模式，保留期必须为 15-24 个月。 + **AWS KMS key** - 指定您的 KMS 密钥。性能详情使用您的 KMS 密钥来加密所有潜在的敏感数据。正在传输的数据和静态数据都会被加密。有关更多信息，请参阅“[加密 Amazon Aurora 资源](Overview.Encryption.md)”。 1. 选择**继续**。 1. 对于**修改计划**，选择**立即应用**。如果您选择**在下一个计划维护时段内应用**，则您的数据库将忽略此设置，并立即开启数据库洞察的高级模式。 1. 选择**修改集群**。 ------ #### [ AWS CLI ] 要在修改数据库集群时开启数据库洞察的高级模式，请调用 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 命令并提供以下值： + `--database-insights-mode advanced`，开启数据库洞察的高级模式。 + `--db-cluster-identifier` – 数据库集群的标识符。 + `--enable-performance-insights`，开启数据库洞察的性能详情。 + `--performance-insights-retention-period`：数据库集群的数据的保留期。要开启数据库洞察的高级模式，保留期必须至少为 465 天。 以下示例在修改数据库集群时启用数据库洞察的高级模式。 对于 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 无限制数据库开启 Database Insights 的标准模式 要为 Aurora PostgreSQL 无限制数据库开启 Database Insights 的标准模式，请按照以下过程操作。 ## 为 Aurora PostgreSQL 无限制数据库创建数据库集群时开启 Database Insights 的标准模式 为 Aurora PostgreSQL 无限制数据库创建数据库时启用 Database Insights 的标准模式。 ------ #### [ Console ] 在控制台中，您可以在创建数据库集群时开启数据库洞察的标准模式。数据库洞察的设置适用于数据库集群中的所有数据库实例。 **在使用控制台创建数据库集群时，开启 Database Insights 的标准模式** 1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。 1. 选择**数据库**。 1. 选择**创建数据库**。 1. 在**数据库洞察**部分，选择**标准模式**。然后，选择以下选项： + **保留** – 保留性能详情数据的时间。要为 Aurora PostgreSQL 无限制数据库创建数据库集群，保留期必须至少为 31 天。 + **AWS KMS key** - 指定您的 KMS 密钥。性能详情使用您的 KMS 密钥来加密所有潜在的敏感数据。正在传输的数据和静态数据都会被加密。有关更多信息，请参阅 [加密 Amazon Aurora 资源](Overview.Encryption.md)。 1. 选择**创建数据库**。 ------ #### [ AWS CLI ] 要在创建数据库集群时打开数据库洞察的标准模式，请调用 [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`，开启数据库洞察的标准模式。 + `--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`，开启数据库洞察的性能详情。 + `--performance-insights-retention-period` – 数据库集群数据的保留期。要为 Aurora PostgreSQL 无限制数据库创建数据库集群，保留期必须至少为 31 天。 + `--monitoring-interval` – 收集数据库集群的增强监控指标的时间点之间的间隔，以秒为单位。该值不能为 `0`。 + `--monitoring-role-arn` – 允许 RDS 将增强监控指标发送到 Amazon CloudWatch Logs 的 IAM 角色的 Amazon 资源名称（ARN）。 + `--enable-cloudwatch-logs-exports` – 您必须将 `postgresql` 日志导出到 CloudWatch 日志。 以下示例在创建数据库集群时启用 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` 设置为无限制数据库的可用引擎版本 + `StorageType` 到 `aurora-iopt1` + `ClusterScalabilityType` 到 `limitless` + `MasterUsername` + `MasterUserPassword` + `EnablePerformanceInsights` 到 `True` + `PerformanceInsightsRetentionPeriod` 设置为至少 `31` 天 + `MonitoringInterval` 设置为非 `0` 的值 + `MonitoringRoleArn` 设置为 IAM 角色的 Amazon 资源名称（ARN），该角色应可以让 RDS 将增强监控指标发送到 Amazon CloudWatch Logs。 ------ ## 为 Aurora PostgreSQL 无限制数据库修改数据库集群时开启 Database Insights 的标准模式 为 Aurora PostgreSQL 无限制数据库修改数据库时开启 Database Insights。 **注意** 要启用数据库洞察，数据库集群中的每个数据库实例都必须具有相同的性能详情和增强型监控设置。 ------ #### [ Console ] 在控制台中，您可以在创建数据库集群时开启数据库洞察的标准模式。数据库洞察的设置适用于数据库集群中的所有数据库实例。 **在使用控制台修改数据库集群时，开启 Database Insights 的标准模式** 1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。 1. 选择**数据库**。 1. 选择数据库集群，然后选择**修改**。 1. 在**数据库洞察**部分，选择**标准模式**。然后，选择以下选项： + **保留** – 保留性能详情数据的时间。要为 Aurora PostgreSQL 无限制数据库创建数据库集群，保留期必须至少为 31 天。 + **AWS KMS key** - 指定您的 KMS 密钥。性能详情使用您的 KMS 密钥来加密所有潜在的敏感数据。正在传输的数据和静态数据都会被加密。有关更多信息，请参阅“[加密 Amazon Aurora 资源](Overview.Encryption.md)”。 1. 选择**继续**。 1. 对于**修改计划**，选择**立即应用**。如果您选择**在下一个计划维护时段内应用**，则您的数据库将忽略此设置，并立即开启数据库洞察的标准模式。 1. 选择**修改集群**。 ------ #### [ AWS CLI ] 要在修改数据库集群时开启数据库洞察的标准模式，请调用 [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`，开启数据库洞察的标准模式。 + `--enable-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 分析 Aurora 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 控制台中查看数据库分片组的 PostgreSQL 日志文件 AWS CLI，也无法像数据库集群那样直接查看 RDS API。您必须使用 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)。 # 使用性能详情监控 Aurora PostgreSQL Limitless Database 使用性能详情监控 Aurora PostgreSQL Limitless Database 集群。性能详情在 Aurora PostgreSQL Limitless Database 上的工作原理与在标准 Aurora 数据库集群上的工作原理类似。但是，您可以在分片组级别跟踪 Aurora PostgreSQL Limitless Database 的指标。 要跟踪的两个主要性能详情指标如下： + 数据库负载 – 衡量数据库中的活动级别。性能详情的关键指标是 `DBLoad`，每秒收集一次。 性能详情中 `DBLoad` 指标的单位是平均活动会话数（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 – 显示哪些查询造成的数据库负载最大。 有关性能详情维度的更多信息，请参阅[尺寸](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions)。 下图显示了数据库分片组的**热门实例**维度。 ![\[数据库分片组的热门实例维度。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) **Topics** + [ # 使用性能详情控制面板分析 Aurora PostgreSQL Limitless Database 的数据库负载 ](USER_PerfInsights.AnalyzeLimitlessTables.md) # 使用性能详情控制面板分析 Aurora PostgreSQL Limitless Database 的数据库负载 借助性能详情，您可以在分片组级别和实例级别跟踪 Aurora PostgreSQL Limitless Database 的指标。在分析 Aurora PostgreSQL Limitless Database 的数据库负载时，您可能需要将每个分片和路由器的数据库负载与最大 vCPU 进行比较。 **注意** Aurora PostgreSQL Limitless Database 始终启用性能详情和增强监控。Limitless Database 的性能详情数据的最短保留期为 31 天（1 个月）。 **绝对**视图显示平均活动会话（AAS）数和预计 vCPU 数。**相对**视图显示 AAS 与预计 vCPU 的比率。 **Topics** + [ ## 使用性能详情控制面板分析 Aurora PostgreSQL Limitless Database 的相对数据库负载 ](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad) + [ # 使用性能详情控制面板按等待状态分析 Aurora PostgreSQL Limitless Database 的数据库负载 ](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md) + [ # 使用性能详情控制面板分析 Aurora PostgreSQL Limitless Database 的负载分配 ](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md) ## 使用性能详情控制面板分析 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. 在导航窗格中，选择**性能详情**。 1. 选择 Aurora PostgreSQL Limitless Database。此时将显示该 Aurora PostgreSQL Limitless Database 的性能详情控制面板。 1. 在**数据库负载（DB 负载）**部分，为**划分者**选择**实例**。要查看 Aurora PostgreSQL Limitless Database 中所有实例的平均活动会话数（AAS）与 vCPU 内核数的比率，请为**查看方式**选择**相对**。 平均活动会话图表显示了您的 Aurora PostgreSQL Limitless Database 中实例的数据库负载。 ![\[查看按实例切片的 Aurora PostgreSQL Limitless Database 的性能详情控制面板。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png) 1. 要查看热门实例，请选择**热门实例**选项卡。 在以下示例中，数据库负载最高的实例是 `DTR-2-2`。 ![\[使用“热门实例”选项卡查看按实例切片的 Aurora PostgreSQL Limitless Database。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) 1. （可选）要分析 Aurora PostgreSQL Limitless Database 中实例的数据库负载，请在**实例**列中选择实例名称。要查看 `DTR-2-2` 的数据库负载，请在**实例**列中选择 `DTR-2-2`。 **注意** 您只能查看 Aurora PostgreSQL Limitless Database 中实例的性能详情指标。 # 使用性能详情控制面板按等待状态分析 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. 在导航窗格中，选择**性能详情**。 1. 选择 Aurora PostgreSQL Limitless Database。此时将显示该 Aurora PostgreSQL Limitless Database 的性能详情控制面板。 1. 在**数据库负载（DB 负载）**部分，为**划分者**选择**等待**。要查看 AAS 和预计 vCPU 的数量，请为**查看方式**选择**绝对**。 平均活动会话图表显示了您的 Aurora PostgreSQL Limitless Database 中实例的数据库负载。 ![\[按等待切片。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png) 1. 向下滚动至 **Top SQL**（热门 SQL）选项卡。 在以下示例中，因等待而导致最高负载的 SQL 语句是 `DELETE` 语句。 ![\[按等待切片时的“热门 SQL”选项卡。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png) 1. 选择 SQL 语句，以将其扩展到其组件语句中。 在以下示例中，`SELECT` 语句有 3 个组件语句。 ![\[选择一条 SQL 语句以将其扩展。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png) # 使用性能详情控制面板分析 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. 在导航窗格中，选择**性能详情**。 1. 选择 Aurora PostgreSQL Limitless Database。此时将显示该 Aurora PostgreSQL Limitless Database 的性能详情控制面板。 1. 在**数据库负载（DB 负载）**部分，为**划分者**选择**实例**。要查看 Aurora PostgreSQL Limitless Database 中所有实例的 AAS 和预计 vCPU 的数量，请为**查看方式**选择**绝对**。 平均活动会话图表显示了您的 Aurora PostgreSQL Limitless Database 中实例的数据库负载。 ![\[查看按实例切片的 Aurora PostgreSQL Limitless Database 的绝对性能详情控制面板。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png) 1. 要查看 Aurora PostgreSQL Limitless Database 中实例的负载分配图表，请选择**负载分配**选项卡。 在以下示例中，数据库负载最高的实例是 `DTR-2-2`。 ![\[当您在实例级别按等待进行切片时的“热门 SQL”选项卡。\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png) # 使用 Amazon GuardDuty RDS 保护功能监控 Aurora PostgreSQL Limitless Database Amazon GuardDuty 是一项威胁检测服务，可帮助保护您的账户、容器、工作负载和 AWS 环境中的数据。GuardDuty 使用机器学习（ML）模型以及异常和威胁检测功能，持续监控不同的日志源和运行时活动，以识别环境中的潜在安全风险和恶意活动并确定其优先级。 GuardDuty RDS 保护会分析和剖析登录事件，找出对 Amazon Aurora 数据库的潜在访问威胁。当您开启 RDS 保护功能时，GuardDuty 会监控来自 Aurora 数据库的 RDS 登录事件。RDS 保护会监控这些事件并对其进行剖析，以了解潜在的内部威胁或外部行为者。 有关 Aurora 中的 GuardDuty RDS 保护功能的更多信息，请参阅[使用适用于 Amazon Aurora 的 Amazon GuardDuty RDS 保护功能监控威胁](guard-duty-rds-protection.md)。 有关启用 GuardDuty RDS 保护功能的更多信息，请参阅《Amazon GuardDuty 用户指南》**中的 [GuardDuty RDS 保护](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。分布式会话在数据库分片组中的路由器上运行，涉及数据库分片组中一个或多个分片上的后端进程。 以下示例演示了如何使用 `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` – 与该分叉中的表关联的 toast 表的大小（以字节为单位）。 + `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 文档中的 [Viewing statistics](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_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** 此视图包含每个节点上每个进程的一行。它可用于跟踪整个系统的运行状况，并对耗时较长的流程进行分类。例如： ``` 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`（文本）– 目标节点上次收集的可用区 + `latency_us`（bigint）– 上次收集的节点间网络延迟，以微秒为单位。如果无法访问该节点，则该值为 `0`。 + `latest_collection`（时间戳）– 最新可用区集合的时间戳和目标节点的延迟 + `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:TwophaseFilePoolRead` 和 `IO:TwophaseFilePoolWrite` 事件，因为这些事件可能会增加分布式事务提交路径的延迟。您可能还想调查网络和 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 个 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()` 则不是。 ## 分配函数 仅访问一个分片上数据的函数应该在该分片上执行，以获得性能优势。函数必须是分布式的，并且函数签名必须包含完整的分片键，即分片键中的所有列都必须作为参数传递给函数。 示例函数： ``` 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) ``` ## 函数和效率模式 在靠近数据的位置执行逻辑会更加高效，而函数在实现这一目标方面起着关键作用。对于使用函数来提高效率，有两个主要使用案例： 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 ``` 执行时间的差异证明了单分片优化的性能优势。