KingbaseES应对表年龄增长过快导致事务回卷

背景

前几天碰到这样一个场景，在KingbaseES数据库当作数据同步节点。其特点是接收过来的数据量巨大，其更新超级频繁，最大的数据库达到6TB.这还不是主要的，主要导致问题发生原因是同步数据库有很多重复数据，为了保证准确性，现在做法的每条数据独立一个事务去完成，这就导致保证同步速度的情况事务age被大量并快速消耗。至于为什么会freeze age，这个就不在这里解释了。大家可以自行百度。

报错信息：

ERROR:  database is not accepting commands to avoid wraparound data loss in database "xxxx"
HINT:  Stop the kingbase and vacuum that database in single-user mode.
You might also need to commit or roll back old prepared transactions.

数据库年龄：

SELECT datname, age(datfrozenxid) FROM pg_database order by age(datfrozenxid) desc;

表年龄：

SELECT n.nspname as "Schema", c.relname as "Name", c.relfrozenxid
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','')
AND n.nspname <> 'information_schema' AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY c.relfrozenxid::text::bigint DESC;

当时查看两个数据库年龄10几亿，其中最大的一张表年龄23亿。难怪数据库告警，事务使用已经超过20亿，没有及时freeze操作。 

解决方法

解决此问题的方法是：

       按照年龄从大到小排序，vacuum 该数据库下每张表。

       每张表的年龄都降下来后，再vacuum该数据库，把数据库年龄也降下来。需要说明的是为了保证解决问题效率，把最大的表vacuum freeze 年龄降下来后就可以登录数据库了，这时候可以在数据库里进行freeze 其他表和数据库的操作。

但是我们知道freeze 是极其消耗IO的动作，对于最大的那张表2965GB的feeze操作至少跑了一晚上，具体花费多旧难以估计。因为第二天来到现场已经跑完了。

之后再vacuum其他表和最终vacuum数据库花了大半天时间，至此问题解决。

 

最后我们要分析问题产生的原因，和怎么规避此次问题。

参数解答

首先了解一个概念很重要：在自动触发(由于表的年龄大于autovacuum_freeze_max_age) 或 手动执行vacuum freeze，或autovacuum触发、手工执行VACUUM时表的年龄大于等于vacuum_freeze_table_age时。以上几种情况的vacuum都将会进入FREEZE模式(扫描全表，并执行freeze)。

有效记录的年龄大于vacuum_freeze_min_age的，将该有效记录设置为freeze状态。普通vacuum(不带freeze的)，并且表的年龄小于vacuum_freeze_table_age，不会执行FREEZE，所以不受这个参数影响。

很显然造成age众多，回收不及时的主要原因是业务同步数据作为每条数据库一个事务而处理，造成表age增长远远超过了vacuum freeze的速度。在无法改变此业务逻辑的前提下。

我们可以尝试修改一下参数：

autovacuum_freeze_max_age=150000000   当表的年龄超过autovacuum_freeze_max_age，即使关闭autovacuum，数据库实例依旧会强行触发vacuum freeze。

vacuum_freeze_table_age      =100000000   当表的pg_class.relfrozenxid年龄大于等于vacuum_freeze_table_age，VACUUM会扫描全表，并执行freeze。

autovacuum_max_workers=5     实际测试发现调大整个参数会导致autovacuum进程过多io消耗满，所以就放弃了。(这还是用了磁盘阵列)

autovacuum_vacuum_scale_factor=0.05   该参数阈值更早的触发vacuum时机。当表的垃圾版本(dead tuples)超过 autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor*reltuples ，触发vacuum。

但注意没有到达vacuum_freeze_table_age 是不会触发freeze操作的。

 

为了避免多张表同一时间进行vacuum ，因为据观察，每张表的age年龄增长几乎都是同步的。

我们可以对年龄增长过快的表单独设置表级别不同的vacuum，freeze 的参数，如下所示，以错开vacuum导致的IO高峰。

autovacuum_vacuum_scale_factor, toast.autovacuum_vacuum_scale_factor (float4)
autovacuum_freeze_max_age, toast.autovacuum_freeze_max_age (整数)
autovacuum_freeze_table_age，toast.autovacuum_freeze_table_age（整数）

autovacuum_vacuum_cost_delay =0

 

结论

然而对于每个参数具体建议值，官方并没有给出最佳建议，毕竟业务场景是多变的。我们只能保守的尝试调整对应参数，再观察每个表对应的age增长情况以及监控IO走势。我们的处理原则是，让autovacuum进场尽量少休息多干活，并且错开每张表的vacuum高峰期，最终保证IO不要负载过高搞崩溃系统。