pg_repack持续运行一周是否符合预期？Amazon Aurora环境下的技术咨询

1. 该现象是否属于当前环境下的正常情况？ #

是的，在你的环境下这种长时间运行是有可能的，核心影响因素包括：

• 超大索引规模：目标表索引占比超过65%（650GB），你使用了-k参数，pg_repack会重建所有索引——重建大索引本身就是IO和CPU密集型操作，再加上Aurora需要同步到2个只读副本，额外增加了存储层的同步开销。
• 高并发写入负载：700-800次/秒的提交速率意味着业务DML非常频繁，pg_repack需要持续处理并发更新、避免与业务冲突，这会大幅拖慢数据迁移和索引重建的进度。
• Aurora架构特性：Aurora的分布式存储层需要将数据同步至多AZ，副本的实时同步机制也会比自建PostgreSQL增加额外的延迟。

你通过性能洞察看到repack.repack_apply持续活跃，说明进程确实在正常推进，没有挂起，只是上述因素共同导致进度极慢。

2. 应该继续让它运行还是取消？ #

建议根据业务影响和资源使用情况决策：

• 优先选择继续运行：如果当前实例的CPU、IOPS、内存等资源未达瓶颈（比如CPU使用率低于70%，无持续IO等待），且业务延迟在可接受范围内，最好继续等待完成——中途取消会浪费已投入的时间，后续重新运行仍要面对相同的负载和规模。
• 考虑取消的场景：如果pg_repack已经导致业务性能下降（如查询延迟飙升、写入超时），或者有紧急维护窗口需要占用资源，再考虑终止进程。

3. 如果选择取消，如何操作才能避免引发问题？ #

pg_repack是设计为安全可中断的，按以下步骤操作即可：

• 优雅终止客户端进程：在EC2的screen会话中直接按下Ctrl+C中断pg_repack客户端，这是最安全的方式，进程会自动清理临时表、触发器等中间对象。
• 手动终止数据库会话：如果客户端无法正常中断（比如screen会话丢失），可以通过psql或Aurora控制台找到对应会话的PID，执行：

  SELECT pg_terminate_backend(pid)
  FROM pg_stat_activity
  WHERE query LIKE '%repack.repack_apply%';
  

• 清理残留对象：如果意外终止导致少量临时对象残留，可以运行以下命令检查并清理：

  pg_repack -h <host> -U <user> -t <tablename> --check <db>
  

取消后不会损坏原表数据，但表的膨胀问题仍会存在。后续可以选择在业务低峰期重新运行，或者考虑升级到最新版pg_repack（1.5.x版本有不少性能优化）；如果表支持分区，也可以尝试分批对分区进行repack来降低单批次负载。

内容的提问来源于stack exchange，提问作者Markus