更改 Databases for EnterpriseDB 配置

Databases for EnterpriseDB 已弃用。从 2025 年 6 月 16 日起，您将无法部署新的实例。现有实例的支持服务将持续到2025年10月15日。届时仍存在的任何实例将被删除。更多信息，请参阅 Databases for EnterpriseDB 的弃用。

IBM Cloud® Databases for EnterpriseDB 可配置为更改某些 PosgreSQL 设置，以便您可以将 Databases for EnterpriseDB 数据库调整为用例。要对数据库配置进行永久更改，请使用 Cloud Databases cli-plugin 或 API 将更改写入部署的配置文件。

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

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

到 CLI 或 API。

在 CLI 中更改 Databases for EnterpriseDB 配置

您可以使用以下选项检查部署的当前配置:

ibmcloud cdb deployment-configuration-schema <deployment name or CRN>

要通过 Cloud Databases cli-plugin 更改配置，请使用 deployment-configuration 命令。

ibmcloud cdb deployment-configuration <deployment name or CRN> [@JSON_FILE | JSON_STRING]

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

在 API 中更改 Databases for EnterpriseDB 配置

存在两个部署配置端点: 一个用于查看配置模式，另一个用于更改配置。要查看配置模式，请向 /deployments/{id}/configuration/schema 发送 GET 请求。

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

有关更多信息，请参阅 API 参考。

可用配置设置

内存设置

shared_buffers

缺省- 32000 (8 KiB 缓冲区数或约 262 MB)
是否重新启动数据库? - 是
选项-最大缓冲区数为 1048576。
Notes-此设置指定 8 KiB 共享内存缓冲区的数目。例如，1 GB 的 shared_buffers 空间是 1048576 KiB, 而（1048576 KiB / 8 KiB ）是 131072 个缓冲区。 shared_buffers 的建议内存分配是部署 RAM 的 25%。设置 shared_buffers 任何更高的值都可能导致导致数据库崩溃的内存问题。设置 shared_buffers 等于，接近等于或大于分配的内存量将阻止数据库启动。根据 PostgreSQL 社区的建议，shared_buffers 的最大总空间为 8 GB 或 1048576 个缓冲区。您的部署可以将更多 RAM 用于高速缓存和性能，即使不将其分配给 shared_buffers 也是如此。您不必将数据库配置为使用所有已分配的 RAM，以便部署使用该 RAM。

常规设置

max_connections

缺省-115
是否重新启动数据库? - 是
注- 在增加最大连接数之前，您可能需要进行扩展。

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
```

WAL 设置

archive_timeout

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

log_min_duration_statement

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

接下来的三个设置 wal_level，max_replication_slots 和 max_wal_senders 允许使用 wal2json 逻辑解码插件。不使用此插件的任何人都应将这些设置保留为缺省值。

wal_level

默认 - hot_standby
重新启动数据库- YES
Notes-控制 WAL 级别。允许的值为 hot_standby 或 logical。设置为逻辑以使用逻辑解码。如果您未使用逻辑解码，那么使用 logical 会增加 WAL 大小，这有几个缺点并且没有实际优势。如果使用 psql 中的 SHOW wal_level; 来检查配置，请注意: 从版本 9.6 起，值 hot_standby 将映射到 replica。

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，那么应将此设置保留为缺省值。