PostgreSQL流复制始终卡在30%进度，求3TB数据完整复制方案

• 网络层面排查

  • 先确认主备之间的网络有没有隐性限制，比如防火墙的流量阈值、云服务器的带宽上限，用iperf3测一下持续吞吐量，看看复制停滞时带宽是不是突然掉下来或者断了。
  • 用mtr或者ping -f持续监控主备间的网络，排查有没有丢包或者超时，很多时候复制停滞都是网络隐性丢包导致的。

• 存储IO瓶颈检查

  • 主库这边，查一下有没有大查询或者长事务占着IO：SELECT pid, query, state, wait_event_type, wait_event FROM pg_stat_activity WHERE state != 'idle';，如果有进程卡在IO等待，先处理掉再重试复制。
  • 备库这边看磁盘负载，iostat -x 1盯着%util指标，如果一直接近100%，就是备库磁盘写不动，跟不上复制节奏。同时查备库的WAL接收状态：SELECT * FROM pg_stat_wal_receiver;，看看received_lsn和replayed_lsn的差距是不是越来越大。

• 系统资源限制验证

  • 检查主备的内存配置，备库的shared_buffers、work_mem如果设得太小，内存不够会导致WAL回放频繁换页拖慢速度，根据服务器内存调整合理值。
  • 看系统文件描述符上限，ulimit -n查一下，要是PostgreSQL进程打开的文件数到顶了，也会卡住，日志里搜too many open files，找不到的话就先把上限调大试试。

• 复制参数深层排查

  • 主库的max_wal_senders是不是够数，要是并发连接多，复制进程可能抢不到资源被阻塞。
  • 备库的wal_receiver_timeout别设太短，网络稍微波动就会断连重试，看似停滞实际在重连，改成60000ms试试。
  • 主库如果开了WAL归档，确认归档进程正常不，要是WAL文件堆着没归档，主库可能停着不发新的WAL。

• 特殊数据对象排查

  • 主库有没有大对象或者死元组特别多的表，这类数据复制时容易卡壳。查一下：SELECT schemaname, tablename, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE n_dead_tup > n_live_tup * 0.5;，找到的话业务低峰期在主库跑VACUUM FULL清理后再重新初始化复制。
  • 手动用pg_basebackup -v初始化备库，看详细进度条，定位到底是卡在哪个表或者阶段，针对性解决。

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