从混乱数据源到PostgreSQLpgloader如何用一条命令完成迁移救赎【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader如果你负责过哪怕一次数据库迁移就一定体会过那种深夜改脚本的滋味。源库表结构千奇百怪日期字段里躺着0000-00-00这种史前怪物CSV 文件里混着带引号的换行符一遇到坏行整批数据就前功尽弃。直到我遇见 pgloader这个号称Migrate to PostgreSQL in a single command的开源工具我的迁移工作才从踩坑连续剧变成了一条命令的事。这篇文章不讲空泛的工具介绍我会按入门、进阶、高手三个台阶带你亲手把一套 SQLite 和 MySQL 的数据完整搬到 PostgreSQL并在最后把最容易翻车的几个坑一次性讲透。读完之后你完全可以自己动手完成一次实战迁移。入门第一课先搞明白它凭什么敢说一条命令传统做法里把 MySQL 的数据搬进 PostgreSQL 通常要经历导出 SQL → 改写类型 → 分批导入三段式中间的坑多到数不清。而 pgloader 的底气来自它的事务与错误处理模型默认情况下PostgreSQL 的批量加载是全有或全无——一行出错整张表回滚pgloader 恰恰相反它把坏行单独写进拒绝文件同时继续把好数据灌进去迁移结束后你拿到一份问题行清单而不是一场灾难。这种差异我用一句话概括COPY 是要么全进要么全不进pgloader 是先进好的坏的一次性清点。另外它内置了数据重写引擎。最典型的就是把 MySQL 的0000-00-00日期自动转成 PostgreSQL 的NULL——因为我们的日历里从来没有公元零年。类似的类型映射规则多达几十条全部可以按需覆盖。在动手之前先把它装好。如果你用的是 Debian/Ubuntu一条命令即可sudo apt-get install pgloader想自己从源码构建也很简单克隆项目后执行make产物在./build/bin/pgloader。如果你的服务器内存紧张可以在编译时降低运行时内存占用make DYNSIZE1024 # 把镜像内存限制到 1GB装好之后跑一句pgloader --version看到版本号就说明一切就绪。第一台阶从 SQLite 迁移体验零配置的爽快现在找一个 SQLite 数据库文件比如项目自带的test/sqlite/sqlite.db执行createdb newdb pgloader ./test/sqlite/sqlite.db postgresql:///newdb就这两行pgloader 会依次完成读取 SQLite 的表结构 → 把类型翻译成 PostgreSQL 对应类型 → 建表建索引建外键 → 并行搬运数据。整个过程不需要你手写任何建表语句这就是它说的single command。预期结果终端实时滚动迁移进度最后打印一张汇总表包含读入行数、错误行数、总耗时。如果源库里确实有数据问题你会看到一个非零的错误计数对应的坏行被写进了/tmp/pgloader/下的拒绝文件里。小贴士数据量大时记得在命令前用createdb提前建好目标库并且确认当前用户对目标库有写权限。如果你希望库名下的结构更清爽可以在迁移后顺手建一个专用 schema——这一步放到配置阶段去做更优雅。第二台阶MySQL 全库搬家认识配置即代码SQLite 场景靠命令行就够了但面对 MySQL 这种动辄几十张表、带外键和自增序列的库命令行会变得臃肿。这时就要请出 pgloader 的命令文件.load它是一套仿 SQL 的 DSL长这样load database from mysql://rootlocalhost/sakila into postgresql:///pagila with concurrency 2, rows per range 50000, create tables, create indexes, reset sequences, foreign keys cast type datetime to timestamptz, type decimal when ( precision 18) and ( scale 6) to double precision drop typemod, type timestamp with extra on update current timestamp to timestamp with time zone drop extra before load do $$ create schema if not exists pagila; $$;这个文件里的每一段都有明确职责from/into源和目标连接串跟命令行写法一致with迁移行为开关create tables表示由 pgloader 建表concurrency 2控制并发度cast类型转换规则这里把 MySQL 的datetime映射为timestamptz把特殊精度decimal(18,6)转成double precisionbefore load do加载前的 SQL 钩子比如先建好 schema。把内容存成migrate.load然后执行pgloader --verbose migrate.load为什么推荐文件而不是命令行因为.load文件本身就是迁移文档——半年后回头看别人读这个文件就知道当初是怎么搬的、做了哪些转换。这是配置即代码带来的最大红利。第三台阶CSV 文件导入掌握三种投喂姿势数据库迁移之外pgloader 对文件类数据源同样得心应手CSV、DBF、IXF、固定宽度文本都支持。以 CSV 为例最朴素的用法是在命令行里直接声明字段pgloader --type csv \ --field id --field name --field created_at \ --with fields terminated by , \ --with truncate \ data.csv postgresql:///mydb?tablenameusers注意目标连接串里的?tablenameusers它告诉 pgloader 数据要灌进哪张表且这张表需要预先建好。文件不在本机两种玩法可以应对HTTP 直取把 CSV 的 URL 当作 source 直接传给 pgloader它会先下载到本地再解析甚至能自动解压 zip 归档。标准输入流把-当作数据源配合 Unix 管道让系统来负责缓冲。比如压缩包里的 CSVcurl -s http://example.com/data.csv.gz \ | gunzip -c \ | pgloader --type csv \ --field usps,geoid,aland \ --with skip header 1 \ --with fields terminated by \t \ - \ postgresql:///mydb?districts这种边下载边解压边灌库的流式写法在处理超大文件时能显著降低磁盘占用。同样叫错误处理pgloader 赢了在哪很多人以为错误处理只是出错了继续跑其实 pgloader 把这件事做得非常系统。我整理了一张踩坑分级对照表方便你对号入座踩坑等级COPY/普通导入的遭遇pgloader 的应对少量坏行整批回滚重头再来坏行进拒绝文件好行照常入库日期脏数据需要预处理脚本清洗内置规则自动转 NULL或走 CAST 定制编码错乱导入后乱码难排查支持指定源文件编码与客户端编码中途断网进度全部丢失分批提交 断点续传配合batch rows具体到配置你可以显式声明错误策略with on error resume next, -- 遇错继续文件类数据源默认行为 max errors 1000, -- 最多容忍 1000 个错误 batch rows 50000, -- 每 5 万行提交一批 prefetch rows 100000 -- 预取 10 万行减少网络往返batch rows和batch size决定了一个批何时闭合批次越小内存越省批次越大吞吐越高——这是性能调优的第一杠杆建议在测试环境多试几组值再定。迁移前必须知道的五个坑最后把我踩过的坑和规避方法一次性交代清楚帮你省掉至少一个通宵。坑 1忘记先建目标库。pgloader 不会替你createdb连接串指向的数据库必须已经存在否则报错极其迷惑。先执行createdb newdb再跑迁移。坑 2大表迁移内存告急。编译时用make DYNSIZE512限制内存运行时调小batch rows与prefetch rows双管齐下。JVM 版本的 pgloader 则直接调整堆内存-Xmx即可。坑 3远程库连接老掉线。在配置文件的set段里加固连接参数set work_mem to 32MB, connect_timeout 120, keepalives 1, keepalives_idle 60, keepalives_interval 10坑 4建索引拖慢全流程。数据量大的表建议加载时先跳过索引灌完数据再统一建with create indexes, max parallel create index 2pgloader 默认在数据加载后建索引必要时也可以配合disable triggers在加载期禁用触发器换取速度。坑 5拿生产库直接试。迁移前务必用--dry-run检查连通性和配置它只做连接验证、不实际搬数据pgloader --dry-run --logfile migrate.log migrate.load跑通 dry-run 再上真刀真枪是每个成熟工程师的底线操作。下一步现在就去备份你的源库工具了解得再透彻不如亲手跑通一次。我的建议行动路径是备份源库与目标库这是所有迁移的前提挑一个最小的库比如某个 SQLite 文件跑通入门命令用--summary生成迁移报告检查行数是否对得上确认无误后再对核心库编写.load文件先--dry-run后正式执行。迁移完成不是终点对账验证才是。拿源库行数与目标库行数逐表比对把拒绝文件里的坏行过一遍——该修数据修数据该补 CAST 补 CAST把这些规则沉淀进你的.load文件里下一次迁移就会又快又稳。数据迁移这件苦差事本质上是被规则和流程驯服的。pgloader 的价值不在于帮你省掉一次打字而在于它把迁移变成了一件可预期、可复查、可复用的工程动作。现在轮到你动手了。【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从混乱数据源到PostgreSQL，pgloader如何用一条命令完成迁移救赎
从混乱数据源到PostgreSQLpgloader如何用一条命令完成迁移救赎【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader如果你负责过哪怕一次数据库迁移就一定体会过那种深夜改脚本的滋味。源库表结构千奇百怪日期字段里躺着0000-00-00这种史前怪物CSV 文件里混着带引号的换行符一遇到坏行整批数据就前功尽弃。直到我遇见 pgloader这个号称Migrate to PostgreSQL in a single command的开源工具我的迁移工作才从踩坑连续剧变成了一条命令的事。这篇文章不讲空泛的工具介绍我会按入门、进阶、高手三个台阶带你亲手把一套 SQLite 和 MySQL 的数据完整搬到 PostgreSQL并在最后把最容易翻车的几个坑一次性讲透。读完之后你完全可以自己动手完成一次实战迁移。入门第一课先搞明白它凭什么敢说一条命令传统做法里把 MySQL 的数据搬进 PostgreSQL 通常要经历导出 SQL → 改写类型 → 分批导入三段式中间的坑多到数不清。而 pgloader 的底气来自它的事务与错误处理模型默认情况下PostgreSQL 的批量加载是全有或全无——一行出错整张表回滚pgloader 恰恰相反它把坏行单独写进拒绝文件同时继续把好数据灌进去迁移结束后你拿到一份问题行清单而不是一场灾难。这种差异我用一句话概括COPY 是要么全进要么全不进pgloader 是先进好的坏的一次性清点。另外它内置了数据重写引擎。最典型的就是把 MySQL 的0000-00-00日期自动转成 PostgreSQL 的NULL——因为我们的日历里从来没有公元零年。类似的类型映射规则多达几十条全部可以按需覆盖。在动手之前先把它装好。如果你用的是 Debian/Ubuntu一条命令即可sudo apt-get install pgloader想自己从源码构建也很简单克隆项目后执行make产物在./build/bin/pgloader。如果你的服务器内存紧张可以在编译时降低运行时内存占用make DYNSIZE1024 # 把镜像内存限制到 1GB装好之后跑一句pgloader --version看到版本号就说明一切就绪。第一台阶从 SQLite 迁移体验零配置的爽快现在找一个 SQLite 数据库文件比如项目自带的test/sqlite/sqlite.db执行createdb newdb pgloader ./test/sqlite/sqlite.db postgresql:///newdb就这两行pgloader 会依次完成读取 SQLite 的表结构 → 把类型翻译成 PostgreSQL 对应类型 → 建表建索引建外键 → 并行搬运数据。整个过程不需要你手写任何建表语句这就是它说的single command。预期结果终端实时滚动迁移进度最后打印一张汇总表包含读入行数、错误行数、总耗时。如果源库里确实有数据问题你会看到一个非零的错误计数对应的坏行被写进了/tmp/pgloader/下的拒绝文件里。小贴士数据量大时记得在命令前用createdb提前建好目标库并且确认当前用户对目标库有写权限。如果你希望库名下的结构更清爽可以在迁移后顺手建一个专用 schema——这一步放到配置阶段去做更优雅。第二台阶MySQL 全库搬家认识配置即代码SQLite 场景靠命令行就够了但面对 MySQL 这种动辄几十张表、带外键和自增序列的库命令行会变得臃肿。这时就要请出 pgloader 的命令文件.load它是一套仿 SQL 的 DSL长这样load database from mysql://rootlocalhost/sakila into postgresql:///pagila with concurrency 2, rows per range 50000, create tables, create indexes, reset sequences, foreign keys cast type datetime to timestamptz, type decimal when ( precision 18) and ( scale 6) to double precision drop typemod, type timestamp with extra on update current timestamp to timestamp with time zone drop extra before load do $$ create schema if not exists pagila; $$;这个文件里的每一段都有明确职责from/into源和目标连接串跟命令行写法一致with迁移行为开关create tables表示由 pgloader 建表concurrency 2控制并发度cast类型转换规则这里把 MySQL 的datetime映射为timestamptz把特殊精度decimal(18,6)转成double precisionbefore load do加载前的 SQL 钩子比如先建好 schema。把内容存成migrate.load然后执行pgloader --verbose migrate.load为什么推荐文件而不是命令行因为.load文件本身就是迁移文档——半年后回头看别人读这个文件就知道当初是怎么搬的、做了哪些转换。这是配置即代码带来的最大红利。第三台阶CSV 文件导入掌握三种投喂姿势数据库迁移之外pgloader 对文件类数据源同样得心应手CSV、DBF、IXF、固定宽度文本都支持。以 CSV 为例最朴素的用法是在命令行里直接声明字段pgloader --type csv \ --field id --field name --field created_at \ --with fields terminated by , \ --with truncate \ data.csv postgresql:///mydb?tablenameusers注意目标连接串里的?tablenameusers它告诉 pgloader 数据要灌进哪张表且这张表需要预先建好。文件不在本机两种玩法可以应对HTTP 直取把 CSV 的 URL 当作 source 直接传给 pgloader它会先下载到本地再解析甚至能自动解压 zip 归档。标准输入流把-当作数据源配合 Unix 管道让系统来负责缓冲。比如压缩包里的 CSVcurl -s http://example.com/data.csv.gz \ | gunzip -c \ | pgloader --type csv \ --field usps,geoid,aland \ --with skip header 1 \ --with fields terminated by \t \ - \ postgresql:///mydb?districts这种边下载边解压边灌库的流式写法在处理超大文件时能显著降低磁盘占用。同样叫错误处理pgloader 赢了在哪很多人以为错误处理只是出错了继续跑其实 pgloader 把这件事做得非常系统。我整理了一张踩坑分级对照表方便你对号入座踩坑等级COPY/普通导入的遭遇pgloader 的应对少量坏行整批回滚重头再来坏行进拒绝文件好行照常入库日期脏数据需要预处理脚本清洗内置规则自动转 NULL或走 CAST 定制编码错乱导入后乱码难排查支持指定源文件编码与客户端编码中途断网进度全部丢失分批提交 断点续传配合batch rows具体到配置你可以显式声明错误策略with on error resume next, -- 遇错继续文件类数据源默认行为 max errors 1000, -- 最多容忍 1000 个错误 batch rows 50000, -- 每 5 万行提交一批 prefetch rows 100000 -- 预取 10 万行减少网络往返batch rows和batch size决定了一个批何时闭合批次越小内存越省批次越大吞吐越高——这是性能调优的第一杠杆建议在测试环境多试几组值再定。迁移前必须知道的五个坑最后把我踩过的坑和规避方法一次性交代清楚帮你省掉至少一个通宵。坑 1忘记先建目标库。pgloader 不会替你createdb连接串指向的数据库必须已经存在否则报错极其迷惑。先执行createdb newdb再跑迁移。坑 2大表迁移内存告急。编译时用make DYNSIZE512限制内存运行时调小batch rows与prefetch rows双管齐下。JVM 版本的 pgloader 则直接调整堆内存-Xmx即可。坑 3远程库连接老掉线。在配置文件的set段里加固连接参数set work_mem to 32MB, connect_timeout 120, keepalives 1, keepalives_idle 60, keepalives_interval 10坑 4建索引拖慢全流程。数据量大的表建议加载时先跳过索引灌完数据再统一建with create indexes, max parallel create index 2pgloader 默认在数据加载后建索引必要时也可以配合disable triggers在加载期禁用触发器换取速度。坑 5拿生产库直接试。迁移前务必用--dry-run检查连通性和配置它只做连接验证、不实际搬数据pgloader --dry-run --logfile migrate.log migrate.load跑通 dry-run 再上真刀真枪是每个成熟工程师的底线操作。下一步现在就去备份你的源库工具了解得再透彻不如亲手跑通一次。我的建议行动路径是备份源库与目标库这是所有迁移的前提挑一个最小的库比如某个 SQLite 文件跑通入门命令用--summary生成迁移报告检查行数是否对得上确认无误后再对核心库编写.load文件先--dry-run后正式执行。迁移完成不是终点对账验证才是。拿源库行数与目标库行数逐表比对把拒绝文件里的坏行过一遍——该修数据修数据该补 CAST 补 CAST把这些规则沉淀进你的.load文件里下一次迁移就会又快又稳。数据迁移这件苦差事本质上是被规则和流程驯服的。pgloader 的价值不在于帮你省掉一次打字而在于它把迁移变成了一件可预期、可复查、可复用的工程动作。现在轮到你动手了。【免费下载链接】pgloaderMigrate to PostgreSQL in a single command!项目地址: https://gitcode.com/gh_mirrors/pg/pgloader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考