30TB本地PostgreSQL 9.6迁移至GCP CloudSQL 12低停机方案咨询

适配迁移工具 #

• 跨版本复制核心工具：开源pglogical2.x版本，适配PostgreSQL 9.6与12的跨大版本逻辑复制需求，CloudSQL 12默认支持该插件无需额外编译，可直接作为从节点对接本地主集群的增量变更
• 大容量全量同步工具：pg_basebackup配合并行压缩工具pigz，相比单线程pg_dump速度提升5~10倍，适配30TB总数据量的批量同步需求
• 一致性校验工具：开源pg_checksums + 自定义行级哈希校验脚本，可批量校验2300个库的表行数、主键哈希值，快速定位不一致数据
• 割接管控工具：本地负载均衡流量封禁规则 + GCP Cloud Load Balancing灰度切流策略，支持秒级流量切换与故障回滚

迁移前置操作规范 #

• 本地PostgreSQL 9.6集群开启配置：wal_level = logical、max_replication_slots≥24（匹配24个集群的复制槽需求）、max_wal_senders≥30（预留冗余避免复制中断），提前安装适配9.6版本的pglogical2.x稳定版
• 本地到GCP专线带宽≥1Gbps，提前测试跨网传输速率，确保30TB全量数据预同步耗时≤72小时
• CloudSQL 12实例配置：24个本地集群对应创建24个独立CloudSQL实例，单实例CPU≥本地集群的1.5倍、内存≥本地集群的2倍、存储预置IOPS≥3000，提前开启pglogical插件授权，配置白名单允许本地集群IP访问5432复制端口
• 提前清理2300个库中的无效临时表、废弃索引，所有无主键表必须补充主键或唯一约束（逻辑复制依赖唯一标识识别行数据）

迁移全流程 #

阶段1：全量预同步（业务零停机） #

• 选择业务低峰期，为每个本地集群单独创建复制槽，使用pg_basebackup配合pigz并行压缩全量备份，直接通过专线传输到GCP后恢复到对应CloudSQL实例，该过程仅占用本地集群10%~15%的IO资源，不影响正常业务运行
• 全量恢复完成后，配置pglogical逻辑复制订阅关系，将CloudSQL设为从节点订阅本地集群的全量DML、DDL增量变更

阶段2：增量同步与一致性校验 #

• 待同步延迟稳定在秒级后，分批对2300个库做数据一致性校验，优先校验核心业务库，非核心库可批量跑脚本校验，出现不一致的表单独做增量补同步
• 持续观测3个以上业务高峰周期，确认同步延迟峰值≤5s，无数据冲突、复制中断问题，提前锁定业务最低峰窗口用于割接

阶段3：业务割接（停机时间≤5分钟） #

• 到达割接窗口后，首先暂停本地集群所有业务写入操作，等待CloudSQL端同步完全部增量数据，确认两端数据100%一致
• 修改业务端数据库连接配置指向CloudSQL实例，先放开10%流量观测1分钟无报错后，逐步全量切流
• 切流完成后持续观测24小时业务运行状态，确认无问题后关闭本地集群的复制槽，下线旧集群

风险防控要求 #

• 所有操作提前在测试环境做1:1模拟演练，记录每个步骤的耗时、异常处理方案，确保实际割接过程零失误
• 割接前提前备份本地集群全量数据，切流后72小时内暂不删除旧集群数据，出现异常可立即切回本地集群
• 迁移过程中禁止对本地集群做表结构变更、插件升级操作，避免逻辑复制中断

内容的提问来源于stack exchange，提问作者JP Dinesh