KingbaseES V8R6在解决复制冲突中hot_standby_feedback参数的重要性

背景

如果我们看到这样的类似报错：那说明可能遇到了复制冲突。

复制冲突的理解：当备库正在应用主库传输过来的wal日志与备库正在进行的查询产生冲突就会有此报错。比如说备库正在执行基于某个表的查询，这时主库执行了drop table操作，该操作写入wal日志落盘后传至备库进行应用，为了保证数据一致性，备库会迅速回放数据，这时主库的操作和备库的查询形成冲突。尤其备库运行长查询时候，查询被取消了就会看到下面的报错。

ERROR：canceling statement due to confilct with recovery。

避免查询冲突的发生

hot_standby_feedback：

这个参数是查询冲突中最重要的参数，下面我们详细探讨一下。我们假设在没有备库的情况下，在主从架构中。设置hot_standby_feedback参数之后备库会定期向主库通知其最小活跃事务id（xmin）值，这就使得主库vacuum时不会清理大于xmin值的事务。

这样就有利于减少冲突的发生，但并不能完全避免冲突，请注意，这个参数只是减少了由于主库vacuum死亡元组造成的冲突，换句话说，并不能解决排他锁造成的冲突。同时还有第三种情况：由于网络中断造成的冲突，假如主备之间的网络中断后，备库就无法向主库正常发送xmin值，如果时间很长，主库在这段时间内还是会清理无用元组，这样网络恢复后就很可能继续发生上面的vacuum和备库造成的冲突。

任何事情都是有利有弊，要根据实际情况，有所取舍，好处就是减少了冲突，缺点就是由于主库的清理需要等待备库的事务结束，那么在频繁更新的场景下，可能造成主库数据膨胀和age的激增。然而，当积累足够多的死亡元组或表age，当备库查询结束，主库集中vacuum时会给I\O带来极致负担。所以我们在生产中设置hot_standby_feedback需要辅助下面参数一起使用，能够有效的降低冲突发生概率。

需要注意的是hot_standby_feedback参数并不会覆盖主库上old_snapshot_threshold参数限定的值，old_snapshot_threshold参数限制了死亡元组的无限膨胀，换句话说当事务信息超过old_snapshot_threshold的限制时，依然会进行清理。所以old_snapshot_threshold是给查询留出的最大限度时间。

max_standby_streaming_delay：

备机由于接收wal流日志产生查询冲突而取消查询之前的等待时间，设置该参数会在发生冲突时，备库查询不会马上取消查询，而是等待一段时间后如果还没结束再抛出报错。这个值的大小可以参考备库可能产生的长事务运行时间。这个参数指startup最多等多久

max_standby_archive_delay：

备机由于应用传输过来的归档日志产生查询冲突而取消查询之前的等待时间，和上面的参数类似，这个参数指startup最多等多久。（restore command 会遇到）

请注意这个参数设置的不合理会造成备库需要更长时间追平主库的数据，这就不能保证主备数据实时一致性。

vacuum_defer_cleanup_age：

指定vacuum延迟清理死亡元组的事务数，延迟的事务个数通过该参数进行设置。（不常用，因为不够具体明确，容易造成膨胀）

我们可以根据pg_stat_database和pg_stat_database_conflicts视图查看冲突的情况。

总结

仔细想一想，流复制本身并没有多大问题，也就是vacuum相关死亡元组必然会应用到备库，甚至我们希望流复制做的速度更快，延迟越小越好，以保证主备最大一致性。那么以上论述最应该避免的是长事务查询，然而主备往往配置了读写分离，在备库读的压力很大时候，加上一些不合理的sql和业务，以此产生了长查询，在oracle中长查询也是不可取的，因为同样可能造成undo表空间中的数据库被覆盖，其实undo中的retention时间就相当于上面提到的old_snapshot_threshold参数，只是undo中多保护了一个guarantee，没有客户不在意成本去无线扩充undo表空间，所以undo表空间往往被设置成非自动扩展，换句话说不允许很长的大查询发生。当然如果是OLTP系统另当别论，而且这也容易造成一致性读相关的性能问题。