概述:pg_repack无锁VACUUM FULL虽然很美妙,但一定要注意突发WAL流量对线上业务的冲击。
当使用pg_repack
清理表时,如果表比较大就需要特别注意。
在最后一步重命名替换的过程中,会产生巨量的WAL。
线上repack脚本中不会处理10G以上的表与索引,那些大对象的清理需要手动确认。
但一张擦边球表,正好10G做了table repack,当进行最后一步替换时,复制落后瞬间飙升。
造成了显著的复制延迟,ReplicationDelay直接飙升到G的级别,阻塞了从库的读取约4分钟左右……,
而且 取!消!不!了! 这就很尴尬了。干看着报警报了4分钟……
- 四分钟左右业务指标下降10%,计划内维护,且影响较小,所以还没算故障。
- 无法取消
- 第一,repack必须放在低谷跑,这样可以降低对复制延迟,网络带宽的冲击。
- 第二,大表的repack一定要非常当心,较大(几个G)的索引与表应当手动检查后清理。