pgcopydb v0.18：从 JSON 转 SQLite，全库克隆提速

公众号数据菌在发呆 |今日栏目数仓与SQL优化pgcopydb v0.18从 JSON 转 SQLite全库克隆提速作为开源维护的工具没有资方支持一般都很难持续。而这次 pgcopydb v0.18 发版回归动作不小88 个提交PostgreSQL 16、17 甚至 18 都兼容了。最明显的变化是底层存储从 JSON 换成了 SQLite。这一改重启安全性和磁盘管理都顺手不少。另外那个--all-databases的全库克隆功能看着像个一键按钮其实背后是把所有库的元数据拉起来做全局调度处理得十分聪明。核心变动SQLite 顶替 JSON做数据迁移的都知道CDC变更数据捕获最怕两件事断点续传时状态丢失或者日志文件无限膨胀。v0.18 把 WAL 解码后的输出存到了output.db已应用的存到replay.db。SQLite 是事务型的进程崩了也不会留下半截写的 JSON 文件导致解析报错。它还支持自动轮转文件超阈值就开新的不用手动去删。还有一个细节过滤规则现在支持正则表达式了。以前得建临时表搞反连接现在直接用数组参数匹配。这意味着可以对只读备库做迁移连锁表都不需要对生产环境比较友好。全库克隆与 Citus 支持以前要迁整个实例得一个个库跑脚本或者用pg_dump拼凑。现在加个--all-databases标志就行。它不是简单地把几个库串起来跑而是先把所有库的元数据抓下来在本地 SQLite 里合并找出最优的 COPY 和索引构建顺序。多路复用操作整体耗时反而比串行低。另外这次补上了 Citus 集群的迁移支持分布列、分区组这些元数据都能处理。如果你还在用 TimescaleDB文档里也加了相关指引。数据菌说这次更新最大的价值不在于“快了多少”而在于“稳了多少”。把 JSON 换成结构化存储解决了很多长期存在的边缘案例。对于中小团队来说这种不需要额外运维成本的稳定性提升比单纯的性能指标更有吸引力。我踩过的坑去年做 Oracle 到 PG 的迁移用旧版工具时遇到过编码问题。源库是 SQL_ASCII里面混着非 UTF-8 的字节序列结果导过去全乱码。这次 v0.18 修复了这个强制客户端编码匹配还增加了二进制不兼容列的自动回退机制转文本 COPY省去了大量手动处理脏数据的精力。落地清单检查源端 PostgreSQL 版本是否在 16-18 范围内升级前备份配置若使用 CDC 功能确认pgoutput插件已启用并配置好复制槽迁移大库前先用--filter测试正则过滤规则避免误杀表生产环境建议订阅官方支持计划确保新 PG 版本发布时的兼容性跟进参考来源Dimitri Fontaine: pgcopydb v0.18— PostgreSQL Planet原文链接https://postgr.es/p/9nWPostgreSQL 官方文档延伸阅读pgcopydb 官方文档延伸阅读Citus 分布式数据库指南延伸阅读