你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

复制/发送服务器

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_slot_wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置复制槽可以保留的最大 WAL 大小。
数据类型	integer
默认值	-1
允许的值	-1
参数类型	（只读）
文档	max_slot_wal_keep_size

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件的大小。
数据类型	integer
默认值	400
允许的值	400
参数类型	（只读）
文档	wal_keep_size

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_slot_wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置复制槽可以保留的最大 WAL 大小。
数据类型	integer
默认值	-1
允许的值	-1
参数类型	（只读）
文档	max_slot_wal_keep_size

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件的大小。
数据类型	integer
默认值	400
允许的值	400
参数类型	（只读）
文档	wal_keep_size

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_slot_wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置复制槽可以保留的最大 WAL 大小。
数据类型	integer
默认值	-1
允许的值	-1
参数类型	（只读）
文档	max_slot_wal_keep_size

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件的大小。
数据类型	integer
默认值	400
允许的值	400
参数类型	（只读）
文档	wal_keep_size

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_slot_wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置复制槽可以保留的最大 WAL 大小。
数据类型	integer
默认值	-1
允许的值	-1
参数类型	（只读）
文档	max_slot_wal_keep_size

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件的大小。
数据类型	integer
默认值	400
允许的值	400
参数类型	（只读）
文档	wal_keep_size

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_slot_wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置复制槽可以保留的最大 WAL 大小。
数据类型	integer
默认值	-1
允许的值	-1
参数类型	（只读）
文档	max_slot_wal_keep_size

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_size

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件的大小。
数据类型	integer
默认值	400
允许的值	400
参数类型	（只读）
文档	wal_keep_size

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_segments

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件数。
数据类型	integer
默认值	25
允许的值	25
参数类型	（只读）
文档

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout

max_replication_slots

属性	值
类别	复制/发送服务器
说明	指定服务器可支持的最大复制槽数。
数据类型	integer
默认值	10
允许的值	2-262143
参数类型	static
文档	max_replication_slots

max_wal_senders

属性	值
类别	复制/发送服务器
说明	设置同时运行的 WAL 发送方进程数量上限。
数据类型	integer
默认值	10
允许的值	5-100
参数类型	static
文档	max_wal_senders

特定于 Azure 的注释

预配 Azure Database for PostgreSQL 灵活服务器实例时设置的 max_wal_senders 服务器参数的默认值不得低于 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication。

在考虑是否需要将 max_wal_senders 增加到更高值以应对大量表的逻辑复制时，请注意以下几点：

• 逻辑复制大量表并不一定需要大量 WAL 发送程序。
• 仅当需要为每个表或每组表分别订阅时，才需要为每个表或每组表分别设置 WAL 发送程序。
• 无论有多少 WAL 发送程序用于物理和逻辑复制，只要有任何后端向预写日志写入内容，它们都会同时变为活动状态。 当发生这种情况时，被分配用于执行逻辑复制的 WAL 发送程序都会唤醒以执行以下操作：
  1. 解码 WAL 中的所有新记录，
  2. 筛选掉它们不感兴趣的日志记录，
  3. 复制与其相关的数据。
• WAL 发送程序与连接类似，因为如果它们处于空闲状态，则数量多少并不重要。 但是，如果它们处于活动状态，它们将争夺相同的资源，性能可能会变得非常糟糕。 对于执行逻辑复制的发送程序而言尤其如此，因为逻辑解码非常消耗 CPU。 每个辅助角色都必须解码整个 WAL，即使它只复制影响单个表的操作，而这只占预写日志中所有数据的很小一部分。 对于物理复制而言，这一点并不重要，因为 WAL 发送程序不会如此密集地消耗 CPU，而且它们首先会受到网络带宽的限制。
• 因此，一般而言，WAL 发送程序的数量最好不要超过 vCore 的数量太多。
• 增加一些额外的 WAL 发送程序以适应未来增长或复制连接的临时激增是一个良好的做法。 以下两个示例可能有助于更好地说明这一点。
  • 对于具有 8 个 vCore、禁用高可用性、2 个读取副本和 3 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (0) + 读取副本的物理槽 (2) + 逻辑槽 (3) + 一些额外的用于未来增长的槽，考虑可用 vCores (1) = 6。
  • 对于具有 16 个 vCore、启用高可用性、4 个读取副本和 5 个逻辑复制槽的服务器，可能需要将 max_wal_senders 配置为以下项的和：高可用性的物理槽 (2) + 读取副本的物理槽 (4) + 逻辑槽 (5) + 一些额外的用于未来增长的槽，考虑可用 vCores (2) = 13。
• 如果你仍然认为此参数允许的最大值太低，无法满足你的需求，请联系我们，详细描述你的场景，并说明你认为要使你的场景正常运行所需的最小可接受值是多少。

track_commit_timestamp

属性	值
类别	复制/发送服务器
说明	收集事务提交时间。
数据类型	boolean
默认值	off
允许的值	on,off
参数类型	static
文档	track_commit_timestamp

wal_keep_segments

属性	值
类别	复制/发送服务器
说明	设置为备用服务器保留的 WAL 文件数。
数据类型	integer
默认值	25
允许的值	25
参数类型	（只读）
文档

wal_sender_timeout

属性	值
类别	复制/发送服务器
说明	设置等待 WAL 复制的最长时间。
数据类型	integer
默认值	60000
允许的值	60000
参数类型	（只读）
文档	wal_sender_timeout