别再熬夜守着数据库迁移pgloader数据迁移实战与避坑指南【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader凌晨两点半办公室只剩显示器还亮着。我第三次点开那个跑了大半天的数据库迁移任务屏幕上红色的ERROR又出现了——这次是因为源表里混进了一行格式异常的数据整个批次的写入被 PostgreSQL 的事务机制直接回滚前面几个小时的努力全部白费只能清空重来。如果你也经历过这种迁移一次、熬夜一周的狼狈那么这篇文章就是为你写的。接下来我要分享的是一个叫pgloader的工具如何把数据库迁移从苦役变成一条命令的事以及新手用它时最容易踩的坑。它支持从 SQLite、MySQL、SQL Server 以及 CSV、DBF、固定宽度文件等多种来源向 PostgreSQL 迁移数据而且出错了它不会停下来。先跑通再说3 分钟让数据动起来 与其听我讲一大堆原理不如先让它干活。下面三个命令任何一条都能让你在几分钟内亲眼看到数据进了 PostgreSQL。第一条把整个 SQLite 数据库搬过去一条命令都不用写配置createdb newdb pgloader ./test/sqlite/sqlite.db postgresql:///newdb它会自己读 SQLite 的表结构、索引、外键建好对应的 PostgreSQL 表再把数据灌进去。第二条不建库直接导 CSV适合临时救火pgloader --type csv \ --field id,name,email \ --with fields terminated by , \ --with truncate \ data.csv postgresql:///mydb?tablenameusers第三条MySQL 全库迁移createdb pagila pgloader mysql://userlocalhost/sakila postgresql:///pagila看到没真正的从零到一只需要这三行量级的操作。想换着花样练习test/目录下躺着几十个官方现成的.load示例文件test/simple.load、test/csv.load都是很好的起步素材。它出错为什么不停一个讲得通的原理 大多数新手第一次用 pgloader 时都会产生同一个疑问迁移过程中明明有数据报错了为什么它还在继续写这科学吗要回答这个问题得先知道 PostgreSQL 自带的COPY命令是什么脾气。COPY是事务性的也就是说一行坏数据就能让整张表的导入功亏一篑。听起来很严谨但在真实世界里脏数据才是常态日期格式五花八门、文本里藏着非法字符、某个字段长度超了……指望源数据干干净净无异于指望加班没有尽头。pgloader 换了个思路它仍然用COPY灌数据但它把一条坏数据和整表失败解绑了。遇到格式不对的行它不会回滚而是把这行原样抄进单独的 reject 文件默认落在/tmp/pgloader/下然后继续处理后面的数据。你可以把它想象成流水线上一个质检员——挑出坏果子扔进旁边的筐里生产线照常运转而不是一发现坏果子就让整条流水线停机。迁移结束后你拿到两个东西成功导入的数据以及一份专门装坏果子的 reject 文件。这份文件就是你的排错清单数据哪行有问题、为什么有问题一目了然。这个设计恰好也是它和全有或全无的COPY之间最本质的差别。迁移前手忙脚乱 vs 迁移后一键完成我最早做数据迁移是这么干的先导 Schema把 MySQL 的建表语句逐条翻译成 PostgreSQL 语法改自增字段、改日期类型再导数据用导出工具生成文件写脚本分批INSERT导完还得回头补索引、补外键、重建序列……整套流程要两三天的工时中间任何一个环节出错都要回头排查半天。用 pgloader 之后这个流程被压缩成了一条命令加一次校验。它内部替你完成了三件事分析源库结构并生成 PostgreSQL 的建表语句按内置规则做类型转换比如把 MySQL 那种不合常理的0000-00-00日期转成NULL因为日历上从来就没有公元零年最后并行地把数据写进去索引、外键、注释、序列一个不落。于是同样的活变成这样写两行LOAD DATABASE ... FROM ... INTO ...白天跑一次测试库验证晚上正式库一把梭早上来瞄一眼 summary 报告收工。以前是人在电脑前等结果现在是结果在等你回来。差别不在工具本身有多炫而在于它把易错的人工环节换成了可复现的配置。新手最容易踩的 5 个坑附报错现象和解决思路这几个坑是我自己真金白银踩出来的每一个都对应一段黑历史。按从蠢到高级排个序坑 1目标数据库根本不存在。报错现象FATAL: database newdb does not exist。 解决思路先createdb newdb再迁移。这是最简单也最常见的翻车点别笑我见过不止一次。坑 2目标表已经存在结构却对不上。报错现象字段数量不匹配、类型冲突一类的ERROR刷屏。 解决思路命令行加--with truncate先清空表如果希望它直接重建表在.load文件里用WITH include drop, create tables。坑 3乱码。报错现象导进去的中文变成????或者直接报编码错误。 解决思路源文件或源库指定编码命令行用--encoding latin1配置文件里用SET client_encoding to latin1。搞清楚源数据是 UTF-8 还是 Latin-1这一步能省掉大量返工。坑 4命令行模式忘了指定表名。报错现象报错说找不到目标表或者数据导进了莫名其妙的表。 解决思路命令行直接导 CSV 时目标表名要写在连接串的?tablename参数里例如postgresql:///mydb?tablenameusers。坑 5误以为它会改源数据。报错现象没有报错但你就是不敢用它跑生产库。 解决思路放心pgloader 对源端是只读的它只会读结构和数据不会写源库。实在不放心先在测试环境对着test/data/里的样例跑一遍亲眼看看它到底做了什么。别急着全自动先走完这条上手路线 踩坑清单看完了接下来给你一条具体的行动路线照着走稳第一步装好它。从源码编译最稳妥git clone https://gitcode.com/gh_mirrors/pg/pgloader进去后执行make可执行文件会出现在./build/bin/下。如果只是临时用发行版软件源里通常也有现成包。第二步拿样例练手。用test/data/里的 CSV 和 DBF 文件配合 docs/quickstart.rst 里的最短示例把上面那三条命令各跑一遍跑通就算入门。第三步写第一份配置文件。从test/simple.load复制一份出来改用WITH和CAST调整行为。想让配置文件怎么写更顺手查阅 docs/command.rst 的语法说明。第四步先体检再上场。对正式任务先加--dry-run只检查连接和结构、不真正灌数据确认无误再去掉它执行。第五步留证据。用--summary report.txt把统计报告留档迁移完了对照检查有没有异常数字。我的建议是第一次正式迁移务必挑一个非核心的表试水跑通全流程再扩大范围。别一上来就全库梭哈给自己留条后路。常见疑问速答Q1pgloader 和 PostgreSQL 自带的 COPY 到底啥关系A它底层就是靠COPY灌数据的但多了一层错误隔离和类型转换等于把 COPY 包装成了不怕脏数据、还会自动建表导数据的进阶版。Q2迁移中报错会不会把源数据弄坏A不会。它对源端只读最多在你的临时目录里生成 reject 文件源库一行都不会动。Q3几十 GB 的大表内存扛不住怎么办A在WITH里调节batch rows每批行数和batch size每批体积把批调小内存占用就下来了。Q4网上有人说 v3 是 Common Lisp 写的现在又冒出个 v4Av4 是官方基于 JVM 的完全重写兼容原来的.load语法发布成单一 JAR只要装了 Java 21 以上就能跑且不用再背 SBCL 运行时的包袱。新项目直接认准 v4 就行。说真的数据迁移不该是让人熬夜的体力活。它应该是写一条命令、跑一个测试、睡一觉、看一眼报告的流程化工作。现在就把第一步迈出去clone 下源码拿一份样例数据敲下你的第一条迁移命令。今晚早点睡让 pgloader 替你守夜。小贴士平时多翻test/目录那是官方自己跑回归测试用的真实配置库。很多配置不知道怎么写的问题答案都躺在这些现成示例里。【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考