把 PostgreSQL 的变更送入分析系统，核心难题是顺序、事务边界、模式变化和故障恢复。物理 WAL 记录的是底层页修改，适合低延迟复制，但消费者要正确理解版本、检查点与复制槽的生命周期。团队应先确认目标是报表延迟、灾备还是搜索索引，再决定使用物理日志、逻辑复制或批处理导出。
WAL 记录了什么
数据库在修改数据页前先写入预写日志，用于崩溃恢复和复制。物理 WAL 面向存储页及其变化，不等同于业务表中的一行记录。它能保留严格顺序，却要求读取端与数据库内部格式和版本保持兼容。逻辑复制更接近表行语义，通常更容易给下游系统消费。
为什么事务边界不能丢
同一笔业务操作可能修改多张表。下游若把事务中的部分变化先暴露给查询，就会产生短暂的不一致。复制程序需要在提交确认后再让目标端可见，并处理回滚、长事务和断线重连。对于分析任务，延迟几秒往往比读到互相矛盾的数据更容易接受。
上线前怎样验证
先选一组有新增、更新、删除和回滚的固定测试数据，比较源端和目标端的行数、主键集合与聚合结果。
- 记录起始日志位置和目标端检查点。
- 制造网络中断并从保存位置恢复。
- 制造消费者重启，确认重复投递不会污染结果。
- 变更表结构，观察消费者如何处理新列和类型变化。
只有持续写入和故障注入都通过，才能证明复制链能恢复，而非只能在正常路径演示。
复制槽和磁盘空间
复制槽会阻止仍被消费者需要的日志过早删除。消费者长期落后时，WAL 文件可能持续堆积并挤满磁盘。监控应包含复制延迟、保留日志量、消费者心跳和源库可用磁盘。发生异常时先保护数据库可用性，再决定是否重建下游数据或推进消费位置。
模式演进怎么处理
分析库字段变更经常比业务库晚一步。新增列可以先允许空值或默认值，重命名和类型转换则需要版本化迁移。不要让下游依赖列在某个固定位置，更不要把内部页格式当作永久 API。升级数据库前，应在相同版本组合中做回放测试。
FAQ
物理 WAL 一定比逻辑复制更快吗
不能这样判断。吞吐量还受解码、网络、目标写入方式和数据模型影响，应该用真实负载测量。
下游重复收到变更怎么办
消费端应保存可追踪的位置，并为写入设计幂等或去重策略。
选择实现前先回答三个问题
先问下游是否需要逐行语义，是否允许最终一致，以及能否承受重建全量数据的时间。报表延迟要求很低而数据规模很大时，物理日志路径可能值得研究。若重点是业务字段同步和表结构易维护，逻辑复制或变更数据捕获往往更容易运维。选型结论应来自恢复演练，而非单项吞吐数字。