max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置复制槽可以保留的最大 WAL 大小。 |
数据类型 |
整数 |
默认值 |
-1 |
允许的值 |
-1 |
参数类型 |
只读的 |
Documentation |
max_slot_wal_keep_size |
max_wal_senders
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_size
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件的大小。 |
数据类型 |
整数 |
默认值 |
400 |
允许的值 |
400 |
参数类型 |
只读的 |
Documentation |
wal_keep_size |
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |
max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置复制槽可以保留的最大 WAL 大小。 |
数据类型 |
整数 |
默认值 |
-1 |
允许的值 |
-1 |
参数类型 |
只读的 |
Documentation |
max_slot_wal_keep_size |
max_wal_senders
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_size
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件的大小。 |
数据类型 |
整数 |
默认值 |
400 |
允许的值 |
400 |
参数类型 |
只读的 |
Documentation |
wal_keep_size |
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |
max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置复制槽可以保留的最大 WAL 大小。 |
数据类型 |
整数 |
默认值 |
-1 |
允许的值 |
-1 |
参数类型 |
只读的 |
Documentation |
max_slot_wal_keep_size |
max_wal_senders
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_size
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件的大小。 |
数据类型 |
整数 |
默认值 |
400 |
允许的值 |
400 |
参数类型 |
只读的 |
Documentation |
wal_keep_size |
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |
max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置复制槽可以保留的最大 WAL 大小。 |
数据类型 |
整数 |
默认值 |
-1 |
允许的值 |
-1 |
参数类型 |
只读的 |
Documentation |
max_slot_wal_keep_size |
max_wal_senders
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_size
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件的大小。 |
数据类型 |
整数 |
默认值 |
400 |
允许的值 |
400 |
参数类型 |
只读的 |
Documentation |
wal_keep_size |
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |
max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_segments
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件数。 |
数据类型 |
整数 |
默认值 |
25 |
允许的值 |
25 |
参数类型 |
只读的 |
Documentation |
|
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |
max_replication_slots
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
指定服务器可支持的最大复制槽数。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
2-262143 |
参数类型 |
静态的 |
Documentation |
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
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置同时运行的 WAL 发送方进程数量上限。 |
数据类型 |
整数 |
默认值 |
10 |
允许的值 |
5-100 |
参数类型 |
静态的 |
Documentation |
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 发送方都会被唤醒:
- 解码 WAL 中的所有新记录,
- 筛选掉他们不感兴趣的日志记录,
- 复制与每个实体相关的数据。
- 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(提交时间戳跟踪)
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
收集事务提交时间。 |
数据类型 |
布尔 |
默认值 |
off |
允许的值 |
on,off |
参数类型 |
静态的 |
Documentation |
track_commit_timestamp |
wal_keep_segments
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置为备用服务器保留的 WAL 文件数。 |
数据类型 |
整数 |
默认值 |
25 |
允许的值 |
25 |
参数类型 |
只读的 |
Documentation |
|
wal_sender_timeout
Attribute |
价值 |
类别 |
复制/发送服务器 |
Description |
设置等待 WAL 复制的最长时间。 |
数据类型 |
整数 |
默认值 |
60000 |
允许的值 |
0-2147483647 |
参数类型 |
dynamic |
Documentation |
wal_sender_timeout |