Azure Database for PostgreSQL 灵活服务器中的限制

适用于:Azure Database for PostgreSQL 灵活服务器

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

最大连接数

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

产品名称 vCore 数 内存大小 最大连接数 最大用户连接数
可突发
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 设置来调整特定时间允许的连接数。 更改此设置后,需要重启服务器,以便新限制开始工作。

注意

虽然可将 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 Database for PostgreSQL 灵活服务器中的连接性能问题

功能限制

以下部分列出了 Azure Database for PostgreSQL 灵活服务器支持的内容和不支持的内容的相关注意事项。

缩放操作

  • 目前,纵向扩展服务器存储需要重启服务器。
  • 只能以 2 倍的增量缩放服务器存储。 有关详细信息,请参阅计算和存储

存储

  • 配置存储大小后,无法减小它。 必须新建具有所需存储大小的服务器,手动执行转储和还原操作,然后将数据库迁移到新服务器。
  • 当存储使用率达到 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

  • Postgres 10 及更低版本不受支持,因为这些版本已被开源社区停用。 如果必须使用其中一个版本,需要使用 Azure Database for PostgreSQL 单一服务器选项,该选项支持较早的主版本 9.5、9.6 和 10。
  • Azure Database for PostgreSQL 灵活服务器支持所有 contrib 扩展等。 有关详细信息,请参阅 PostgreSQL 扩展
  • 内置的 PgBouncer 连接池程序当前不适用于可突发服务器。

停止/启动操作

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

计划性维护

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

服务器备份

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

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

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

服务器还原

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

后续步骤