管理 Amazon Aurora PostgreSQL - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

管理 Amazon Aurora PostgreSQL

下文将介绍如何管理 Amazon Aurora PostgreSQL 数据库集群的性能和扩缩。还包括有关其他维护任务的信息。

扩展 Aurora PostgreSQL 数据库实例

您可通过两种方式扩展 Aurora PostgreSQL 数据库实例,即实例扩展和读取扩展。有关读取扩展的更多信息,请参阅读取扩展

您可以修改数据库集群中的每个数据库实例的数据库实例类,以扩展 Aurora PostgreSQL 数据库集群。Aurora PostgreSQL 支持多种针对 Aurora 优化的数据库实例类。不要将 db.t2 或 db.t3 实例类用于大小超过 40 TB 的较大 Aurora 集群。

注意

建议仅将 T 数据库实例类用于开发和测试服务器,或其他非生产服务器。有关 T 实例类的更多详细信息,请参阅数据库实例类类型

扩缩不会即时完成。可能需要 15 分钟或更长时间才能完成对其他数据库实例类的更改。如果使用此方法修改数据库实例类,则应在下一个计划的维护时段内(而不是立即)应用更改,从而避免影响用户。

作为直接修改数据库实例类的替代方法,您可以使用 Amazon Aurora 的高可用性特征最大限度地减少停机时间。首先,将 Aurora 副本添加到集群中。创建副本时,选择要用于集群的数据库实例类大小。Aurora 副本与集群同步后,您可以故障转移至新添加的副本。要了解更多信息,请参阅Aurora 副本Amazon Aurora PostgreSQL 的快速故障转移

有关 Aurora PostgreSQL 支持的数据库实例类的详细规格,请参阅数据库实例类支持的数据库引擎

至 Aurora PostgreSQL 数据库实例的最大连接数

Aurora PostgreSQL 数据库集群根据数据库实例类及其可用内存分配资源。与数据库集群的每个连接都会占用这些资源(如内存和 CPU)的增量。每个连接占用的内存取决于查询类型、计数以及是否使用临时表。即使是空闲连接也会占用内存和 CPU。这是因为当查询在连接上运行时,系统将为每个查询分配更多内存,而且即使处理停止,内存也不会完全释放。因此,建议您确保应用程序不会占用空闲连接:每个空闲连接都会浪费资源并对性能产生负面影响。有关更多信息,请参阅空闲 PostgreSQL 连接占用的资源

Aurora PostgreSQL 数据库实例允许的最大连接数量由该数据库实例的参数组中指定的 max_connections 参数值确定。max_connections 参数的理想设置是既能支持应用程序所需的所有客户端连接,又不会有太多未使用的连接,外加至少 3 个支持 Amazon 自动化的连接。修改 max_connections 参数设置之前,建议您考虑以下内容:

  • 如果 max_connections 值太低,当客户端尝试连接时,Aurora PostgreSQL 数据库实例可能没有足够的可用连接。如果发生这种情况,尝试使用 psql 进行连接会引发如下错误消息:

    psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
  • 如果 max_connections 值超过了实际需要的连接数,未使用的连接可能会导致性能降低。

max_connections 的默认值源自以下 Aurora PostgreSQL LEAST 函数:

LEAST({DBInstanceClassMemory/9531392},5000).

如果要更改 max_connections 的值,您需要创建自定义数据库集群参数组并在其中更改其值。将自定义数据库参数组应用到集群之后,请务必重启主实例,这样新值才能生效。有关更多信息,请参阅 Amazon Aurora PostgreSQL 参数创建数据库集群参数组

提示

如果您的应用程序经常打开和关闭连接,或使大量长期连接保持打开,我们建议您使用 Amazon RDS 代理。RDS 代理是一种完全托管的高可用性数据库代理,它使用连接池安全有效地共享数据库连接。要了解有关 RDS 代理的更多信息,请参阅将 Amazon RDS 代理用于 Aurora

有关 Aurora Serverless v2 实例如何处理此参数的详细信息,请参阅 Aurora Serverless v2 的最大连接数

Aurora PostgreSQL 的临时存储限制

Aurora PostgreSQL 将表和索引储存在 Aurora 存储子系统中。Aurora PostgreSQL 对于非持久性临时文件使用单独的临时存储。这包括用于在查询处理过程对大型数据集进行排序或者用于索引构建操作等用途的文件。有关更多信息,请参阅文章如何解决 Aurora PostgreSQL 兼容实例中的本地存储问题?

这些本地存储卷由 Amazon Elastic Block Store 提供支持,并可以通过使用更大的数据库实例类来进行扩展。有关存储的更多信息,请参阅 Amazon Aurora 存储和可靠性

注意

当扩展数据库实例(例如,从 db.r5.2xlarge 扩展到 db.r5.4xlarge)时,您可能会看到 storage-optimization 事件。

下表显示了每个 Aurora PostgreSQL 数据库实例类可用的最大临时存储空间。有关 Aurora 的数据库实例类支持的更多信息,请参阅 Aurora 数据库实例类

数据库实例类 最大可用临时存储空间 (GiB)
db.x2g.16xlarge1829
db.x2g.12xlarge1606
db.x2g.8xlarge1071
db.x2g.4xlarge535
db.x2g.2xlarge268
db.x2g.xlarge134
db.x2g.large67
db.r7g.16xlarge 1008
db.r7g.12xlarge 756
db.r7g.8xlarge 504
db.r7g.4xlarge 252
db.r7g.2xlarge 126
db.r7g.xlarge 63
db.r7g.large 32
db.r6g.16xlarge 1008
db.r6g.12xlarge 756
db.r6g.8xlarge 504
db.r6g.4xlarge 252
db.r6g.2xlarge 126
db.r6g.xlarge 63
db.r6g.large 32
db.r6i.32xlarge 1829
db.r6i.24xlarge 1500
db.r6i.16xlarge 1008
db.r6i.12xlarge 748
db.r6i.8xlarge 504
db.r6i.4xlarge 249
db.r6i.2xlarge 124
db.r6i.xlarge 62
db.r6i.large 31
db.r5.24xlarge 1500
db.r5.16xlarge 1008
db.r5.12xlarge 748
db.r5.8xlarge 504
db.r5.4xlarge 249
db.r5.2xlarge 124
db.r5.xlarge 62
db.r5.large 31
db.r4.16xlarge 960
db.r4.8xlarge 480
db.r4.4xlarge 240
db.r4.2xlarge 120
db.r4.xlarge 60
db.r4.large 30
db.t4g.large 16.5
db.t4g.medium 8.13
db.t3.large 16
db.t3.medium 7.5

您可以使用 FreeLocalStorage CloudWatch 指标监控数据库实例可用的临时存储,如Amazon Aurora 的 Amazon CloudWatch 指标中所述。(这不适用于 Aurora Serverless v2。)

对于某些工作负载,您可以通过为执行操作的进程分配更多内存来减少临时存储量。要增加操作可用的内存,请增加 work_memmaintenance_work_mem PostgreSQL 参数的值。

Aurora PostgreSQL 的大页

大页是一项内存管理特征,可以减少数据库实例处理大量连续内存数据块(例如共享缓冲区使用的内存数据块)时的开销。Aurora PostgreSQL 的当前所有可用版本都支持这项 PostgreSQL 特征。

对于除 t3.medium、db.t3.large、db.t4g.medium、db.t4g.large 实例类之外的所有数据库实例类,默认情况下都会开启 Huge_pages 参数。您无法在 Aurora PostgreSQL 支持的实例类中更改 huge_pages 参数值或关闭此特征。