复制/发送服务器

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

max_slot_wal_keep_size

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_size

wal_sender_timeout

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

max_slot_wal_keep_size

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_size

wal_sender_timeout

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

max_slot_wal_keep_size

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_size

wal_sender_timeout

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

max_slot_wal_keep_size

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_size

wal_sender_timeout

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_segments

wal_sender_timeout

max_replication_slots

特定于 Azure 的注释

参数的 max_replication_slots 默认值为 10。 如果启用高可用性，则至少需要 4 个 max_replication_slots 才能正常运行。

对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_replication_slots 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_replication_slot。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。

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，并且它们往往首先受到网络带宽的限制。
• 因此，一般情况下，最好没有比 vCore 更多的 WAL 发送方。
• 最好为一些额外的 WAL 发送方添加空间，以适应复制连接的未来增长或临时峰值。 以下两个示例可能有助于更好地说明它。
  • 对于具有 8 个虚拟核心、禁用 HA、2 个只读副本和 3 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（0）+ 只读副本的物理槽（2）+ 逻辑槽（3）和一些适用于未来增长的余量，综合考虑可用的虚拟核心 （1） = 6。
  • 对于具有 16 个 vCore、已启用 HA、4 个只读副本和 5 个逻辑复制槽的服务器，您可能需要将 max_wal_senders 配置为 HA 的物理槽（2）+ 只读副本的物理槽（4）+ 逻辑槽（5）+ 一些额外的用于将来增长，考虑可用的 vCore（2）= 13。
  • 如果启用高可用性，则至少需要 4 个 max_wal_senders 才能正常运行。 对于启用了高可用性的服务器，加上 5 个只读副本和 12 个逻辑复制槽，您可能需要将 max_wal_senders 配置为 21。 这是因为每个只读副本和每个逻辑复制槽都需要一个 max_wal_senders。 因此，它总共需要 1（插槽）* 5（只读副本）+ 12（逻辑复制插槽）+ 4（用于确保高可用性正常运行）= 21。
• 如果你仍然认为此参数允许的最大值太低，以满足你的需求，请 与我们联系，详细描述你的方案，并说明你认为，这是你为方案正确执行所需的最小可接受值。

track_commit_timestamp（提交时间戳跟踪）

wal_keep_segments

wal_sender_timeout