Aurora PostgreSQL写入节点突发高io:xactsync等指标异常排查咨询

问题背景 #

问题已持续3周，每3-4天发作一次。环境为AWS RDS Aurora PostgreSQL，写入实例规格为db.r6g.xlarge，包含：

• 6个从RDS复制数据到S3的DMS任务
• 1个跨AWS账户、向该RDS迁移数据的DMS任务

突发时表现：复制槽关联的CPU、io:xactsync、IO:ReorderBufferRead和IO:ReorderBufferWrite指标飙升，但峰值时段复制槽无大量DML操作。停止本账户所有DMS任务后问题消失，恢复任一任务后问题会持续30-45分钟再消失，升级实例至db.r6g.2xlarge后问题仍存在。已采集5小时区间的CloudWatch指标（CPU&磁盘队列深度、会话&网络、IO、DB负载、Top SQL）。

排查方向建议 #

1. 复制槽状态与积压检查 #

• 查询pg_replication_slots视图，重点关注restart_lsn、confirmed_flush_lsn、active字段，确认是否存在LSN积压或僵尸复制槽（任务已停止但槽未清理）。即使无大量DML，积压的LSN可能触发后台ReorderBuffer同步操作，导致IO/CPU飙升。
• 检查DMS任务的CDC捕获模式，若为全量+增量混合模式，任务重启后的快照同步残留可能触发批量ReorderBuffer读写。

2. 数据库参数调优核查 #

• 确认max_replication_slots、wal_keep_size、max_wal_senders参数配置，多个DMS任务并行时，是否因资源竞争导致复制槽同步效率下降。
• 检查reorder_buffer_size参数：值过小会导致ReorderBuffer频繁读写磁盘；值过大则占用过多内存引发换页，间接提升IO负载。

3. DMS任务资源配置排查 #

• 查看每个DMS任务的并行加载/捕获线程数，是否因配置过高导致多任务抢占复制槽资源，引发后台同步的资源竞争。
• 排查跨账户DMS任务的网络延迟，若跨账户传输存在抖动，可能导致复制槽LSN确认滞后，触发本地IO重试与同步逻辑。

4. Aurora存储层IO瓶颈验证 #

• 结合CloudWatch IO指标，确认突发时磁盘IOPS、吞吐量是否达实例上限。即使升级实例规格，若存储层（如GP2）IOPS瓶颈未解决，仍会导致ReorderBuffer相关IO指标飙升。
• 检查Aurora读写分离配置，确认复制流量是否正确路由到只读实例，避免写入实例承担额外复制压力。

5. 后台进程与锁状态排查 #

• 突发时抓取pg_locks、pg_stat_activity视图，确认是否存在与复制槽相关的长事务锁或后台进程阻塞（如wal_sender进程阻塞），导致ReorderBuffer读写操作积压。
• 监控pg_stat_replication视图，查看write_lag、flush_lag、replay_lag是否异常升高。

6. DMS任务过滤规则与数据类型适配检查 #

• 检查DMS任务的表过滤规则，是否存在大量小表的频繁同步，单表DML量小但多表叠加触发ReorderBuffer频繁操作。
• 确认是否同步大字段（TEXT、BYTEA等），这类字段的ReorderBuffer处理会消耗更多IO与CPU资源，即使DML量小也可能引发性能波动。

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