Kingbase 流复制相关参数

一、发送服务器端

1. max_wal_senders = 6

同时允许wal sender 进程的最大数量。Wal sender 进程被计算在连接总数内，因此该参数不能被设置大于
max_connections。

2. max_replication_slots=5

服务器支持的复制槽最大数量。如果该值小于现有的复制槽数量，
将会阻止数据库启动。

3. wal_keep_segments=256

sys_xlog目录下所能保留的过去日志文件段的最大数目。每个wal_segment_size = 16MB * 256 = 4096 MB。

4. wal_sender_timeout = 60s

中断停止活动超过该值的复制连接。检测后备机崩溃或网络中断，设置为0则禁用该机制。

5. track_commit_timestamp = off

记录事务提交时间。

二、主服务器

1. synchronous_standby_names='1(Node71,Node72,Node73)'

指定支持同步复制的后备服务器列表。在后备服务器接收并应返回值后，主服务器才会提交其他事务。
后备服务器返回值参考wal参数synchronous_commit。 
num_sync(standby_name1,standby_name2 [, ...])：基于优先级的多同步复制机制
num_sync: 事务需要等待其回复的同步后备服务器数量
standby_name: 是后备服务器的名称

如：2(s1,s2,s3) 三个运行的后备服务器
主库提交事务时，必须等待s1、s2 接收并写入wal 日志文件，
然后才能返回给客户端成功。
S3是一个潜在同步后备，当s1、s2中的任意一个失效，它将升级为同步备库。

同步模式比异步模式增加了响应时间，用性能换取了安全。
当同步备库全部宕机时，会阻塞主库的事务。

2. vacuum_defer_cleanup_age = 0

指定vacuum 和 HOT更新 在清除死亡元组之前，应该推迟多久(以事务数量计)。即vacuum 和 vacuum full 不会立即
清理刚刚被删除的元组。默认是0个事务，表示死亡版本尽可能块的被清除，即当它们不再对任何打开的事务可见时尽快清除。

为了防止slave 端读取数据时，因为读到的是旧有数据而被强制取消，设定了这么一个以transaction为单位的值。

三、后备服务器

1. hot_standby=on

slave端在恢复期间，是否能够连接并运行查询。即不只是用户数据归档，而且用于数据查询。

2. max_standby_archive_delay = 30s，默认单位毫秒。

-1 表示允许后备机一直等到冲突查询结束。
备机因为处理归档的wal 日志产生查询冲突而取消查询之前等待的时间。
设置该参数会在发生冲突时，备库查询不会立即取消，而是等待一个时间后如果还没结束再抛出报错。
该值大小可以参考备库可能产生的长事务运行时间。

3. max_standby_streaming_delay = 30s，默认单位毫秒。

-1 表示允许后备机一直等到冲突查询结束。
备机因为接受wal 流日志产生查询冲突而取消查询之前等待的时间。和上面参数类似。

4. wal_receiver_status_interval = 10s

备机上的wal 接收进程向主机发送有关复制进度信息的最小频度。
即备机多久向主机报告一次状态，每次数据复制都会向主机报告状态，这里指最长间隔。

5. hot_standby_feedback=on

指定热后备机是否向主机或上游后备机发送有关后备机上当前正被执行查询的反馈。
这个参数用来排除记录清除导致的查询取消，但是也可能会造成主数据库膨胀。
反馈消息的频度不会高于wal_receiver_status_interval 周期性发送一次。

假设在没有备库的情况下，会话1查询某行数据，会话2删除该数据，然后commit，此时会话2执行一次vacuum，
我们知道这次vacuum并不会删除该行数据，因为会话1的事务还需要使用该元组，所以不会清理该元组。
那么如果是主从呢？主库在准备进行vacuum时怎么知道从库还在进行查询，这就是设置该参数的意
义，设置hot_standby_feedback参数之后备库会定期向主库通知最小活跃事务id（xmin）值，这样使得
主库vacuum进程不会清理大于xmin值的事务。

这个参数有利于减少冲突的发生，但并不能完全避免冲突。这个参数只是减少了由于主库vacuum 死亡元组造成的冲突，
并不能解决其他排它锁的冲突。

这个参数设置有利有弊，好处是减少了冲突，缺点就是主库的清理需要等待备库的事务结束。在频繁更新的场景下，
就有可能造成主库数据膨胀。
这个参数与以上几个参数配合使用，可以有效降低冲突发生的概率。

需要注意的是，hot_standby_feedback参数并不会覆盖主库上old_snapshot_threshold = -1 参数限定的值。
old_snapshot_threshold 限制了死亡元组的无限膨胀，当事务信息超过old_snapshot_threshold 的限制时，
依然会进行清理。

设置hot_standby_feedback 的原因：
流复制是基于wal日志的复制技术，主库不断发送wal日志至备库，备库进行应用回放。
但是有时我们可能会在备库进行某个查询，然后遇到查询中途突然抛出如下错误：

ERROR：canceling statement due to confilct with recovery

报错中我们可以看出，查询取消的原因是因为和恢复进程发生了冲突。那么为什么会产生冲突呢？
我们细想一下，比如说备库正在执行基于某个表的查询
（这个查询可能是应用产生的，也可能是手动连接进行的查询），这时主库执行了drop table操作，
该操作写入wal日志后传至备库进行应用，为了保证
数据一致性，postgresql必然会迅速回放数据，这时drop table和select就会形成冲突。如下图所示：

问题原因：

1.主库由于请求排它锁的操作传递到备库产生的冲突，如上图所示，主库执行drop table、truncate table、
alter table 等操作，在备库进行回放时有可能与备库正在进行的查询冲突。

2.由于主库vacuum 清理掉无用元组造成的冲突。当某些频繁更新或删除的表中，vacuum 进程发现某个页面中全部都是dead tuple(死亡元组)时，会尝试
请求排它锁进行清理，这样的话可能与备库的查询产生冲突。比如主库vacuum 掉了备库查询所需要的元组时，就会产生冲突。

3.网络中断，假如主备之间网络中断，备机无法向主机正常发送xmin值，如果时间够长，主库在这段时间内，还是会清理无用元组，这样网络恢复后，就有可能
会发生上面vacuum 造成的冲突。

问题预防：

设置如上5个参数进行查询冲突的控制+配置vacuum_defer_cleanup_age 。

生产环境中，可以根据sys_stat_database 和 sys_stat_database_conflicts 视图查看冲突发生的情况，以此来进行如上参数的调整。

6. wal_receiver_timeout = 60s

中止处于非活动状态超过指定毫秒数的复制链接。对于后备服务器检测主机崩溃或网络中断有用。值为0时禁用此超时机制。

7. wal_retrieve_retry_interval = 5s

指定备份服务器在wal 数据不可从任何源(流复制、本地sys_xlog或wal 归档) 可用之前等待多长时间，然后再尝试检索wal 数据。
在恢复中的节点，需要控制等待新的wal 数据可用的时间量的配置中，该参数有用。
例如: 在归档恢复中，通过降低该参数的值，可以检测到新的wal 日志文件时，使恢复更敏感。

参考文章: https://blog.csdn.net/xiaohai928ww/article/details/98469656