共用方式為

Azure Database for PostgreSQL 中的限制

以下部分介绍 Azure Database for PostgreSQL 灵活服务器实例的容量和功能限制。 如果想了解资源(计算、内存、存储)层,请参阅文章 - 计算存储

最大连接数

下表显示了每个定价层和 vCore 配置的默认最大连接数。 Azure Database for PostgreSQL 灵活服务器实例保留 15 个连接,用于物理复制和监视 Azure Database for PostgreSQL 灵活服务器实例。 因此,该表将最大用户连接数的值从总最大连接数减少 15。

产品名称 vCores 内存大小 最大连接数 最大用户连接数
Burstable
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
常规用途
D2s_v3/D2ds_v4/D2ds_v5 2 8 GiB 859 844
D4s_v3/D4ds_v4/D4ds_v5 4 16 GiB 1,718 1,703
D8s_v3/D8ds_V4/D8ds_v5 8 32 GiB 3,437 3,422
D16s_v3/D16ds_v4/D16ds_v5 16 64 GiB 5,000 4,985
D32s_v3/D32ds_v4/D32ds_v5 32 128 GiB 5,000 4,985
D48s_v3/D48ds_v4/D48ds_v5 48 192 GiB 5,000 4,985
D64s_v3/D64ds_v4/D64ds_v5 64 256 GiB 5,000 4,985
D96ds_v5 96 384 GiB 5,000 4,985
内存优化
E2s_v3/E2ds_v4/E2ds_v5 2 16 GiB 1,718 1,703
E4s_v3/E4ds_v4/E4ds_v5 4 32 GiB 3,437 3,422
E8s_v3/E8ds_v4/E8ds_v5 8 64 GiB 5,000 4,985
E16s_v3/E16ds_v4/E16ds_v5 16 128 GiB 5,000 4,985
E20ds_v4/E20ds_v5 20 160 GiB 5,000 4,985
E32s_v3/E32ds_v4/E32ds_v5 32 256 GiB 5,000 4,985
E48s_v3/E48ds_v4/E48ds_v5 48 384 GiB 5,000 4,985
E64s_v3/E64ds_v4/E64ds_v5 64 432 GiB 5,000 4,985
E96ds_v5 96 672 GiB 5,000 4,985

保留的连接槽(目前为 15 个)可能会更改。 建议定期确认服务器上保留的连接总数。 通过对 reserved_connectionssuperuser_reserved_connections 服务器参数的值求和来计算此数字。 最大可用用户连接数为 max_connections - (reserved_connections + superuser_reserved_connections)。

在配置 Azure Database for PostgreSQL 灵活服务器实例时,系统会根据计算功能所选的产品名称计算 max_connections 服务器参数的默认值。 对支持实例的计算进行产品选择的任何后续更改都不会影响该实例的服务器参数的默认值 max_connections 。 建议每次更改分配给实例的产品时,还根据上表中的值调整 max_connections 参数的值。

更改 max_connections 值

首次设置 Azure Database for Postgres 灵活服务器实例时,该实例会自动决定它可同时处理的最大连接数。 服务器的配置确定此数字,无法更改它。

但是,可以使用 max_connections 设置来调整特定时间允许的连接数。 更改此设置后,需要重启服务器,以便新限制开始工作。

Caution

虽然可将 max_connections 的值设置为超出默认设置,但不建议这样做。

当工作负载扩展并需要更多内存时,实例可能会遇到困难。 随着连接数的增加,内存使用量也会增加。 内存有限的实例可能会遇到崩溃或高延迟等问题。 尽管当大多数连接处于空闲状态时,一个更高的 max_connections 值是可接受的,但在所有连接处于活动状态后,这可能会导致显著的性能问题。

如果需要更多连接,建议改用 PgBouncer,它是用于连接池管理的内置 Azure 解决方案。 在事务模式下使用它。 首先,建议使用保守值,即乘以 2 到 5 范围内的 vCore 数。 之后,请仔细监视资源利用率和应用程序性能,以确保顺利运行。 有关 PgBouncer 的详细信息,请参阅 Azure Database for PostgreSQL 中的 PgBouncer

当连接数超出限制时,可能会收到以下错误:

FATAL: sorry, too many clients already.

将 Azure Database for PostgreSQL 灵活服务器实例用于具有大量并发连接的繁忙数据库时,资源可能会产生很大的压力。 这种压力可能会导致 CPU 使用率过高,尤其是在同时建立多个连接以及连接持续时间短(少于 60 秒)时。 这些因素可能会增加处理连接和断开连接所花费的时间,从而对数据库的整体性能产生负面影响。

无论 Azure Database for PostgreSQL 灵活服务器实例中的每个连接是空闲还是处于活动状态,都会消耗数据库中的大量资源。 这种消耗可能导致不止是 CPU 使用率高的性能问题,例如磁盘和锁争用。 PostgreSQL Wiki 上的 数据库连接数 文章更详细地讨论了本文。 若要了解详细信息,请参阅 在 Azure Postgres 中识别并解决连接性能问题

功能限制

Azure Database for PostgreSQL 灵活服务器实例支持和不支持的注意事项列在以下各节中。

扩展运营

  • 目前,纵向扩展服务器存储需要重启服务器。
  • 服务器存储只能以 2 倍递增进行扩展。 有关详细信息,请参阅 存储
  • 我们目前不支持减少服务器存储大小。 执行此操作的唯一方法是导出并恢复到新的 Azure Database for PostgreSQL 灵活服务器实例。

存储

  • 配置存储大小后,无法减小它。 必须新建具有所需存储大小的服务器,手动执行转储和还原操作,然后将数据库迁移到新服务器。
  • 当存储使用率达到 95% 或可用容量小于 5 GiB(无论更多)时,系统会自动将服务器切换到 只读模式 ,以避免与磁盘完全相关的错误。 在极少数情况下,如果数据增长速度超过切换到只读模式所需的时间,服务器可能仍会耗尽存储。 你可以启用存储自动增长以避免这些问题,并根据工作负载需求自动缩放存储。
  • 建议针对 storage usedstorage percent 超过特定阈值的情况设置警报规则,以便能主动提前采取措施,例如增加存储大小。 例如,可以设置一个存储使用率百分比超过 80% 时触发的警报。
  • 如果使用逻辑复制,则在相应的订阅服务器不再存在时,必须删除主服务器中的逻辑复制槽。 否则,预写日志 (WAL) 文件将在主存储中累积并将其填满。 如果存储超出特定阈值,并且逻辑复制槽未使用(由于订阅服务器不可用),则 Azure Database for PostgreSQL 灵活服务器实例会自动删除未使用的逻辑复制槽。 此操作会释放累积的 WAL 文件,并防止因为存储已满而导致服务器不可用。
  • 我们不支持创建表空间。 如果要创建数据库,请不要提供表空间名称。 Azure Database for PostgreSQL 灵活服务器实例使用模板数据库继承的默认表空间。 提供表空间(如临时表空间)并不安全,因为我们无法确保此类对象在服务器重启和高可用性 (HA) 故障转移等事件后将保持持久性。

网络

  • 我们目前不支持移入和移出虚拟网络。
  • 目前不支持将公共访问与虚拟网络中的部署相结合。
  • 虚拟网络不支持防火墙规则。 可以转而使用网络安全组。
  • 公共访问数据库服务器可以连接到公共 Internet(例如通过 postgres_fdw)。 不能限制这种访问。 虚拟网络中的服务器可以通过网络安全组限制出站访问。

高可用性

可用性区域

  • 目前不支持手动将服务器移动到其他可用性区域。 但是,通过使用首选可用性区域作为备用区域,可以启用 HA。 建立备用区域后,可以故障转移到该区域,然后关闭 HA。

Postgres 引擎、扩展和 PgBouncer

  • Azure Database for PostgreSQL 灵活服务器实例支持 PostgreSQL 引擎的所有功能,包括分区、逻辑复制和外部数据包装器。
  • Azure Database for PostgreSQL 灵活服务器实例支持所有 contrib 扩展和更多功能。 有关详细信息,请参阅 PostgreSQL 扩展
  • 可突发服务器目前无法访问内置的 PgBouncer 连接池程序。

停止/启动操作

  • 停止 Azure Database for PostgreSQL 灵活服务器实例后,它会在七天后自动启动。

计划性维护

  • 可以将自定义维护时段更改为一周中的任何一天/时间。 但是,在收到维护通知后所做的任何更改都不会影响下一次维护。 更改仅在下次月度计划性维护时生效。

服务器备份

  • 备份由系统进行管理。 当前无法手动运行备份。 我们推荐改用pg_dump

  • 第一个快照是完整备份,连续快照则是差异备份。 差异备份仅备份自上次快照备份以来更改的数据。

    例如,如果数据库的大小为 40 GB,并且预配的存储为 64 GB,则第一个快照备份为 40 GB。 现在,如果更改了 4 GB 的数据,则下一个差异快照备份大小将仅为 4 GB。 事务日志(预写日志)独立于完整备份和差异备份,并且会持续存档。

服务器还原

  • 使用时间点还原(PITR)功能时,系统将创建与它所基于的服务器相同的计算和存储配置的新服务器。
  • 从备份还原时,系统会将虚拟网络中的数据库服务器还原到同一虚拟网络中。
  • 还原期间创建的新服务器没有原始服务器上存在的防火墙规则。 需要为新服务器单独创建防火墙规则。
  • 我们不支持恢复到其他订阅。 解决方案是,可以还原同一订阅中的服务器,然后将还原的服务器迁移到其他订阅。

安全性

  • Postgres 14及更高版本禁用了MD5哈希,系统仅使用SCRAM-SHA-256方法对Postgres本地密码进行哈希。