IBM Cloud Docs
更改 Databases for PostgreSQL 配置

更改 Databases for PostgreSQL 配置

IBM Cloud® Databases for PostgreSQL 允许您更改某些 PostgreSQL 配置设置，以便可以根据您的用例调整 PostgreSQL 数据库。 要对数据库配置进行永久更改，请使用 Cloud Databases CLI 插件 或 API 将更改写入部署的配置文件。

配置是在模式中定义的。 要进行更改，请将包含设置及其新值的 JSON 对象发送到 API 或 CLI。 例如，要将 max_connections 设置设置为 150，您将提供:

{"configuration":{"max_connections":150}}

到 CLI 或 API。

有关详细信息，请参阅 管理 PostgreSQL 连接。

将 CLI 与 Databases for PostgreSQL 配合使用

您可以使用 deployment-configuration-schema 命令来检查部署的缺省配置。

ibmcloud cdb deployment-configuration-schema <INSTANCE_NAME_OR_CRN>

同样，使用 deployment-configuration 命令更改配置。

ibmcloud cdb deployment-configuration <INSTANCE_NAME_OR_CRN> [@JSON_FILE | JSON_STRING]

此命令将读取要从 JSON 对象或文件进行的更改。 有关更多信息，请参阅 参考页面。

将 API 与 IBM Cloud® Databases for PostgreSQL 配合使用

两个 deployment-configuration 端点允许查看配置模式和更改配置。 要查看配置模式，请向 /deployments/{id}/configuration/schema 发送 GET 请求。

要更改配置，请将您希望在 PATCH 请求的请求主体中更改为 JSON 对象的设置发送到 /deployments/{id}/configuration。

有关详细信息，请参阅 API 参考。

可用的 IBM Cloud® Databases for PostgreSQL 配置设置

IBM Cloud® Databases for PostgreSQL 时区设置

IBM Cloud® Databases for PostgreSQL 部署的时区始终为 UTC (全球标准时间)。 客户机无法配置此设置。

IBM Cloud® Databases for PostgreSQL 内存设置

shared_buffers

  • 缺省- 32000 (8 KiB 缓冲区数或约 262 MB)
  • 建议的最大值: 可用 RAM 的 25%
  • 是否重新启动数据库? - 是

shared_buffers 的建议内存分配是部署 RAM 的 25%。 设置 shared_buffers 任何更高的值都可能导致导致数据库崩溃的内存问题，并且可能会降低数据库的性能，因为数据很可能已由操作系统缓冲。 将 shared_buffers 设置为等于，接近等于或大于分配的内存量会阻止数据库启动。 此设置指定 8 KiB 共享内存缓冲区的数目。

例如，1 GB shared_buffers 空间为 1048576 KiB，(1048576 KiB / 8 KiB) 为 131072 个缓冲区。 您的部署可以使用额外的 RAM 进行高速缓存和性能，即使不将其分配给 shared_buffers 也是如此。 您不必将数据库配置为使用所有已分配的 RAM，以便部署使用该 RAM。

对于现有工作负载，或者在扩展 RAM 时，将内存增加到共享缓冲区可能不是最佳操作过程。 而是跟踪表和索引高速缓存命中率。 如果高速缓存命中率在 90% 以下，那么让操作系统使用其他区域中的内存，而不是增加 shared_buffers。

您可以使用这些查询作为 admin 用户或具有 pg_monitor 角色的任何用户来跟踪高速缓存命中率:

Tables

SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as table_hit_ratio
FROM
  pg_statio_user_tables;

索引

SELECT
  sum(idx_blks_read) as idx_read,
  sum(idx_blks_hit)  as idx_hit,
  (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as index_hit_ratio
FROM
pg_statio_user_indexes;

work_mem 值将在与 shared_buffer 和 max_connection 配置值的关系中自动调整。

IBM Cloud® Databases for PostgreSQL 常规设置

max_connections

max_locks_per_transaction

  • 缺省-64
  • 选项-最小值 10
  • 是否重新启动数据库? - 是

max_prepared_transactions

  • 默认 - 0
  • 是否重新启动数据库? - 是
  • Notes-缺省值 0 将禁用 已准备的事务，除非您需要使用这些事务，否则建议使用这些事务。

synchronous_commit

  • 默认 - local
  • 重新启动数据库-否
  • 选项- local，on 或 off
  • 注-将 synchronous_commit 设置为 off 会提高事务落实率，但如果发生不干净的关闭，那么会牺牲已落实事务的丢失。 如果 synchronous_commit 设置为 on，那么仅当将事务写入引导者和至少一个副本时，才会落实该事务。 因此，on 设置仅在已水平缩放到至少三个成员的构造上可用。 实施此更改前，请参阅 高可用性。

effective_io_concurrency

  • 默认 - 12
  • 重新启动数据库-否
  • Notes-建议将此设置保留为缺省值。 仅当您对 SQL 查询进行了概要分析并观察到低效位图堆扫描时，才会增大此值。 由于 IOPS 与磁盘大小绑定，因此也不建议在缺省或较小大小的磁盘上增大此设置。

deadlock_timeout

  • 默认 - 10000
  • 重新启动数据库-否
  • 选项-最小值 100
  • Notes-检查死锁之前要等待的毫秒数以及记录锁定等待的持续时间。 通过 日志记录集成提供的日志。 将此数字设置得过低会对性能产生负面影响。

log_connections

  • 默认 - off
  • 重新启动数据库-否
  • 选项- on 或 off 的值
  • Notes-将此值设置为 on 会使日志详细。 它还显示监视工具的连接，因为它每 60 秒抽取一次度量值。 设置为 on 时，建议在连接 URI 中设置 application_name 以在日志中保留概述，因为显示的 IP 地址是 Kubernetes 内部 IP。 有关调整连接 URI 的详细信息可在 PostgreSQL 文档中找到。 设置为 off 时，不会将行为更改为缺省设置，也不会记录任何连接。 可通过 日志记录集成 获取日志。 如果设置了 on，那么日志将显示类似于以下示例的行，其中应用程序名称设置为 test-app:
2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

  • 默认 - off
  • 重新启动数据库-否
  • 选项- on 或 off 的值
  • Notes-将此值设置为 on 会使日志详细。 它还将显示监视工具的断开连接情况，因为它每 60 秒抽取一次度量值。 设置为 on 时，建议在连接 URI 中设置 application_name 以在日志中保留概述，因为显示的 IP 地址是 Kubernetes 内部 IP。 有关调整连接 URI 的详细信息可在 PostgreSQL 文档中找到。 设置为 off 时，不会将行为更改为缺省设置，也不会记录断开连接。 可通过 日志记录集成 获取日志。 如果设置了 on，那么日志将显示类似于以下示例的行，其中应用程序名称设置为 test-app:
2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638

log_min_duration_statement

  • 默认 - 100
  • 重新启动数据库-否
  • 选项-最小值 100
  • Notes-记录耗时超过指定毫秒数的语句。

tcp_keepalives_idle

  • 默认 - 111
  • 重新启动数据库-否

tcp_keepalives_interval

  • 默认 - 15
  • 重新启动数据库-否

tcp_keepalives_count

  • 默认 - 6
  • 重新启动数据库-否

IBM Cloud® Databases for PostgreSQL WAL 设置

archive_timeout

  • 默认 - 1800
  • 重新启动数据库-否
  • 选项-最小值 300
  • Notes-强制切换到下一个 WAL 文件之前等待的秒数。 如果已经过秒数，并且存在数据库活动，那么服务器将切换到新段。 有效限制数据可以保持未归档的时间量。

接下来的三个设置 wal_level，max_replication_slots 和 max_wal_senders 允许使用 wal2json 逻辑解码插件。 如果未使用此插件，请将这些设置保留为缺省值。

wal_level

  • 默认 - replica
  • 重新启动数据库- YES
  • Notes-控制 WAL 级别。 允许的值为 replica 或 logical。 设置为 logical 则使用逻辑解码。 如果不使用逻辑解码，使用 logical 会增加 WAL 的大小，这样做有几个缺点，并没有真正的好处。

max_replication_slots

  • 默认 - 10
  • 重新启动数据库- YES
  • Notes-同时定义的复制槽的最大数目。 缺省插槽数和最小插槽数为 10。 为实现高可用性 (HA) 目的，您的部署保留了 20 个插槽供内部使用。 要使用插槽，需要将值设置为 20 以上，并且每个使用者有一个插槽。 为每个期望的使用者添加一个额外的插槽。 使用 wal2json 而不增加 max_replication_slots 可能会影响 HA 和只读副本。 如果未使用 wal2json，请将此设置保留为缺省值。

max_wal_senders

  • 默认 - 12
  • 重新启动数据库- YES
  • Notes-同时运行的 WAL 发送方进程的最大数目。 缺省值 (最小值) 为 12。 每个使用者需要一个 wal_sender。 为实现高可用性 (HA) 目的，您的部署保留了 20 个插槽供内部使用。 您需要将该值设置为高于 20，建议在每个预期使用者的最小值之外再添加一个 wal_sender。 使用 wal2json 而不增加 max_wal_senders 可能会影响 HA 和只读副本。 如果未使用 wal2json，请将此设置保留为缺省值。