KingbaseES 物理备库影响主库的性能与垃圾回收
前言
KingbaseES 物理备库有些配置可能影响到主库性能，或者反过来说主库某些配置也会影响到备库。终极原因还是heap tuple 和dead tuple放在一起导致的。
首先，原理上讲，物理备库就是基于KingbaseES WAL流式复制。物理备库在物理层面与主库完全一致，每一个数据块都一样。物理备库允许在实时恢复的同时，对外提供只读的功能。通常生产环境很多部署读写分离集群。这就会带来我们熟知的备库的查询冲突问题。
问题来了，只读操作可能和恢复会发生冲突，比如用户正在备库读某个数据块的数据，与此同时，实时恢复进程读取到WAL的记录，发现需要修改这个数据块的数据。此时恢复就与只读发生了冲突。
为了避免冲突，数据库有哪些方式呢？
- 主库配置
1.1 vacuum_defer_cleanup_age
设置主库垃圾回收的延迟，例如配置为1000，表示垃圾版本将延迟1000个事务再被回收，默认为0。
- 备库配置
2.1 hot_standby_feedback
如果设置为ON，备库在执行QUERY时会通知主库，哪些版本需要被保留，不能被VACUUM。
2.2 max_standby_archive_delay， max_standby_streaming_delay
表示当备库的QUERY与恢复进程发生冲突时，恢复进程最长的等待时间，当恢复进程从被冲突堵塞开始等待时间超过以上设置时，会主动KILL与之发生冲突的QUERY，然后开始恢复，直到catch up，才允许QUERY与恢复进程再次发生冲突。
问题分析
以上配置，要么影响主库，要么影响备库。都是有一定代价的。
- vacuum_defer_cleanup_age > 0
代价1，主库膨胀，因为垃圾版本要延迟若干个事务后才能被回收。
代价2，重复扫描垃圾版本，重复耗费垃圾回收进程的CPU资源。（n_dead_tup会一直处于超过垃圾回收阈值的状态，所以autovacuum 不断唤醒worker进行回收动作）。
当主库的 autovacuum_naptime=很小的值，同时autovacuum_vacuum_scale_factor=很小的值时，尤为明显，对性能影响更大。
代价3，如果期间发生大量垃圾，垃圾版本可能会在事务到达并解禁后，爆炸性的被回收，产生大量的WAL日志，从而造成WAL的写IO问题，这也是主题中提到的造成IO的性能问题。
- hot_standby_feedback=on
如果备库出现了LONG QUERY，或者Repeatable Read的长事务，并且主库对备库还需要或正查询的数据执行了更新并产生了垃圾时，主库会保留这部分垃圾版本（与vacuum_defer_cleanup_age效果类似）。
代价，与vacuum_defer_cleanup_age > 0 类似。
- max_standby_archive_delay， max_standby_streaming_delay
代价，如果备库的QUERY与APPLY（恢复进程）冲突，那么备库的apply会出现延迟，也许从备库读到的是N秒以前的数据。
影响主库的问题复现
前面分析了，当主库设置了vacuum_defer_cleanup_age > 0或者备库设置了hot_standby_feedback=on同时有LONG QUERY时，都可能造成主库的3个问题。
这个问题很容易复现。
复现方法1 备库hot_standby_feedback=on
开启主库的自动垃圾回收，同时设置为很小的唤醒时间，以及很小的垃圾回收阈值。
这样设置是为了防止膨胀，但是也使得本文提到的问题更加的明显。
test=# show autovacuum_naptime ;
-[ RECORD 1 ]------+---
autovacuum_naptime | 1s
test=# show autovacuum_vacuum_scale_factor ;
-[ RECORD 1 ]------------------+-------
autovacuum_vacuum_scale_factor | 0.0002
- 创建测试表
test=# create table test(id int , info text, crt_time timestamp);
- 插入1000万测试数据
test=# insert into test select 1,md5(random()::text),now() from generate_series(1,10000000);
- 在hot standby上开启一个repeatable read事务，执行一笔QUERY，查询test的全表
test=# begin transaction isolation level repeatable read;
BEGIN
test=# select count(*) from test ;
count
----------
10000000
(1 row)
- 在主库更新test全表
test=# update test set info=info;
- 查询test表当前的统计信息，有1000万条dead tuple
test=# select * from pg_stat_all_tables where relname ='test';
-[ RECORD 1 ]-------+------------------------------
relid | 17621
schemaname | public
relname | test
seq_scan | 1
seq_tup_read | 10000000
idx_scan |
idx_tup_fetch |
n_tup_ins | 10000000
n_tup_upd | 10000000
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 10000000
n_dead_tup | 10000000
- 造成的影响，读IO巨大（扫描test表，试图回收垃圾，但是回收未成功），以及autovacuum worker的CPU开销很大。
因为autovacuum worker process 不停被唤醒，扫描垃圾数据，但是不能对其进行回收，所以n_dead_tup一直不会下降，循环往复，autovacuum worker不断被唤醒。极端情况cpu会被占满。
问题处理
- 备库设置参数hot_standby_feedback=off
hot_standby_feedback = off
reload
问题马上解除，垃圾被回收掉了。
test=# select * from pg_stat_all_tables where relname ='test';
-[ RECORD 1 ]-------+------------------------------
relid | 17621
schemaname | public
relname | test
seq_scan | 1
seq_tup_read | 10000000
idx_scan |
idx_tup_fetch |
n_tup_ins | 10000000
n_tup_upd | 10000000
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 10000000
n_dead_tup | 0
autovacuum worker不会再被唤醒，所以主库的CPU马上下降。
同时注意垃圾回收会带来一次很大的WAL写IO。
- max_standby_archive_delay， max_standby_streaming_delay起作用是，备库的事务在apply冲突超时后，被强制kill
test=# show hot_standby_feedback;
hot_standby_feedback
----------------------
off
(1 row)
test=# select count(*) from test ;
count
----------
10000000
(1 row)
test=# select * from test limit 10;
FATAL: terminating connection due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
复现方法2 主库vacuum_defer_cleanup_age > 0
略，复现方法一样。
小结与优化
为了尽量的避免物理备库的QUERY与apply的冲突，KingbaseES提供了几种方法，但是这些方法要么影响主库，要么影响备库。都有一定代价。
上例已描述代价。
引申，还有一些行为可能会导致垃圾记录(dead tuple)无法被回收，一旦dead tuple无法被回收，那么每次autovacuum worker都是无用功。同样会引发和本文类似的问题（autovacuum不停被唤醒）。 例如
-
主库有LONG XACT，无法回收该事务ID后产生的垃圾。(9.6可以设置snapshot too old，针对只读事务，如果事务超过配置的时间（或者XID），不好的是可能遇到快照过旧的错误，好处是避免一直无法垃圾回收的问题。)
-
主库有LONG 2PC XACT，无法回收该事务ID后产生的垃圾。(9.6可以设置snapshot too old，针对只读事务，如果事务超过配置的时间（或者XID），不好的是可能遇到快照过旧的错误，好处是避免一直无法垃圾回收的问题。)
紧急解决这个问题的办法很简单，cancel long query,xact,2pc xact即可。
- 如果复制槽失效，在主备切换后有可能导致此问题，那么就会导致主库有大量dead tuple无法回收。
优化建议
-
不建议设置 vacuum_defer_cleanup_age > 0
-
如果备库有LONG query，同时需要实时性，可以设置hot_standby_feedback=on，同时建议将主库的autovacuum_naptime，autovacuum_vacuum_scale_factor设置为较大值（例如60秒，0.1），主库的垃圾回收唤醒间隔会长一点，但是如果突然产生很多垃圾，可能会造成一定的膨胀。
-
如果备库有LONG QUERY，并且没有很高的实时性要求，建议设置设置hot_standby_feedback=off, 同时设置较大的max_standby_archive_delay， max_standby_streaming_delay。
以上优化各有利弊，我还是觉得最好是把主库dml和备库query分开不同时间执行。
建议参数如下:
hot_standby_feedback = off
autovacuum_naptime=45s
vacuum_freeze_min_age = 50000000
vacuum_freeze_table_age = 1300000000
vacuum_multixact_freeze_min_age = 50000000
vacuum_multixact_freeze_table_age = 1300000000
autovacuum_freeze_max_age = 1500000000
autovacuum_multixact_freeze_max_age = 1500000000
- 备库配置recovery.conf中如果设置了使用SLOT，也可能导致主库wal堆积，导致主库的dead tuple不清理（对应SLOT备库需要的不清理）。
Replication slots provide an automated way to ensure that the master does not remove WAL segments until they have been received by all standbys, and that the master does not remove rows which could cause a recovery conflict even when the standby is disconnected.
