干数据库这行，最怕听到的词就是“迁移”。一提起要把PG（PostgreSQL）的数据搬到新环境，不少人的第一反应是眉头一皱，脑子里立刻浮现出停机、丢数据、业务投诉的连环噩梦。但说实话，这几年我经手过几十套PG系统的迁移，从几百GB的小库到几十TB的核心库都碰过，发现这事儿真没想象中那么玄乎。只要把路数摸清了，数据切换可以做到跟换轮胎一样平稳——车还在跑，轮子已经换完了。
很多人一上来就纠结用哪个工具，其实顺序反了。迁移的第一步，永远不是选工具，而是搞清楚你的“家底”。我见过最惨的案例，是某公司直接拿生产库的物理文件拷到新机器，结果因为PG的小版本不一致，数据文件格式对不上，库直接起不来。所以，动手之前先花半天时间做个体检：查一下源库的版本号、插件列表、字符集、大表分布，还有那些容易忽略的“定时任务”和“外部表”。特别是字符集，如果源库是SQLASCII，目标库想用UTF8，那后面就算用最牛的工具，乱码问题也够你喝一壶。体检报告出来，迁移方案基本就定了一半。
工具选型这事儿，没必要赶时髦。PG生态里，pgdump和pgrestore这对老搭档，对付10GB以下的小库，依然是最稳的。逻辑导出虽然慢点，但胜在兼容性好，跨大版本迁移基本靠它。库一超过几百GB，就得请出物理复制的大神——pgbasebackup。这玩意儿直接拷贝数据目录，速度是逻辑备份的几倍，还能顺便把WAL日志一起带走，做到几乎零丢失。至于那些追求不停机的场景，那就要上逻辑复制的神器了，比如pglogical或者内置的发布订阅功能。我个人的经验是，能用内置的发布订阅就别折腾第三方插件，毕竟原生功能踩坑少，社区资料也全。
说个真实的坑。去年帮一家电商公司做迁移，他们库里有张3亿行的订单表，索引建了七八个。用pgdump导出时，光这张表就跑了两个小时，导入的时候更惨，因为要重建索引，目标库的CPU直接飙到100%。后来我换了思路，导出时用参数开并行，导入前先干掉非关键索引，数据灌完再一次性重建。就这么一调，总耗时从五小时压缩到四十分钟。所以，别迷信某个工具，关键得学会组合拳——大表用并行导出，小表走常规通道，索引后置，这招比什么高级工具都管用。
数据搬过去只是第一步，真正的考验在切换那一刻。我见过太多团队，数据同步完了，业务一切流量，立马发现应用连不上库，或者查询慢如蜗牛。问题往往出在连接串、权限，还有那些不起眼的数据库参数上。比如，源库的是500，新库默认才100，流量一上来直接报too many clients。还有密码加密方式，PG15之后默认是scram-sha-256，老应用如果用md5认证，不调整配置根本登不进去。所以，我习惯在正式切换前，列一个“参数对齐清单”，把sharedbuffers、workmem、wallevel这些关键项逐一比对，别偷懒，这半小时能省下后面几天的苦。
切换演练这事儿，真得当成正经事来办。别心疼那几小时时间，演练不是走流程，是逼着问题提前暴露。我带队做迁移时，至少会安排三次演练：第一次在测试环境，纯属验证流程跑不跑得通；第二次在预发环境，带着模拟流量跑，看看有没有锁冲突和延迟；第三次才是正式切换前的“带妆彩排”，所有操作步骤精确到分钟，连回滚方案都要演练一遍。有一次演练还真救了我们——发现切换后有个定时任务会往新库写数据，但那个任务的权限没配好，直接报错。如果不是提前发现，真到生产切换那晚，估计得通宵救火。
回滚方案，很多人觉得是摆设，但我劝你务必认真写。做迁移最怕的不是回滚，而是没有回滚的勇气。我见过一个团队，切到新库后发现性能不达标，但为了赶上线节点，硬扛着没回滚，结果业务投诉雪片一样飞来，花了三天才灰溜溜切回去。我的原则是：切换窗口定在流量最低的凌晨，但回滚窗口留足48小时。数据同步工具别急着关，万一新库出问题，随时能切回老库，数据还能续上。这就像开车走山路，安全带可以不系，但刹车必须保证灵。
文章开头我说迁移没那么难，现在我得补充一句：不难的前提，是你把每一步都当回事。工具是死的，人是活的。我见过用最原始的pgdump迁移上百GB库成功的，也见过用最贵的商业工具翻车的。差别就在，你有没有提前摸清数据分布、有没有做足参数对齐、有没有把演练和回滚当回事。PG这套数据库，本身就给足了迁移的“弹药”——物理复制、逻辑复制、在线工具，全是开源免费的。你唯一要做的，就是把这些工具用出“量身定制”的感觉来。
说句掏心窝子的：数据无缝切换不是魔术，是流程管理。你花在规划上的每一分钟，都会在切换那晚变成实实在的安稳觉。别怕迁移，怕的是不做功课就硬上。把体检、工具、参数、演练、回滚这五件事做到位，PG迁移就是一次普通的版本升级，甚至比升级还稳。下次再有人跟你说PG迁移难，你可以把这篇文章甩给他，然后补一句：“只要路数对，这事儿真不难。”
