引言

本次迁移采用 AWS、GCP 双活架构。业务迁移完成前，GCP 所有服务均读写 AWS 侧数据库。

迁移收尾最大难点：将应用数据库连接池从 AWS 切换至 GCP。

DNS 域名切换无法同步销毁存量长连接，会出现新旧两套连接池并行读写同一数据表，同时提交事务直接产生脏数据。

相信很多无专职运维团队的中小公司开发者，跨云迁移都会踩同类坑，本文完整记录我单人完成万级设备平台数据库切换的两套落地方案。

方案选型

方案——单点爆破

前置逻辑：迁移全程新旧业务统一读写 AWS 旧库，GCP 新库作为从库持续同步数据。

AWS 旧库前置 Nginx TCP 代理，GCP 环境所有服务通过域名访问 AWS 旧库。链路：GCP 服务 → 域名 → AWS 旧库 Nginx 代理 → AWS MySQL。

仅需修改三处配置：

1. GCP 环境所有服务的数据库连接池配置

2. AWS 旧库 MySQL 参数配置

3. AWS 旧库前置的 Nginx TCP 代理配置

关键配置约束：统一固定 GCP 环境所有服务的数据库连接数，关闭空闲自动回收，维持长连接稳定。

等全量业务迁移至 GCP 后，将域名解析切到 GCP 新库地址。TCP 长连接只在建立时解析一次域名。切 DNS 后，存量连接不受影响，仍保持旧库连接；由于连接数已固定且空闲不回收，不会产生新连接，因此没有新建连接会解析到新库。风险窗口可控。

待域名全网解析生效，确认 GCP 新库已完全追平数据、主从无延迟后，直接停止AWS 旧库前置 Nginx。

Nginx 一停，所有存量 TCP 连接同步断开，业务服务随即自动重连至 DNS 指向的 GCP 新库。整个切换过程，统一、批量、一步到位。

这套“一刀切”方案的底气来自业务特征：平台并发高峰集中在饭点宠物喂食批量上报，其余绝大多数请求是网关拦截处理的设备心跳，真正抵达业务库的写请求极少。只要避开喂食高峰操作，风险极低。

优势： 改动配置少、操作链路短，从根源杜绝多服务切换时序不一致导致的脏数据。切换后仅需清理少量连接断开报错日志——非常适合单人独立推进迁移。

兜底与回滚机制：

在 GCP 新库服务器部署一套备用 TCP 代理 Nginx，监听 3306 端口，流量转发回 AWS 旧库。提前调试通整套代理配置后临时停止，留存作为回滚预案。

之所以复用 3306 端口，是因为所有业务服务的数据库端口配置已固化，无法临时修改。代理端口必须与业务原有配置一致，才能做到无缝切换。

这套代理就是迁移的“后悔药”：一旦 GCP 新库出现数据异常，只需停掉本机 MySQL 进程，启动备用 Nginx，全量业务流量会瞬间切回 AWS 旧库，业务无感知恢复。兜底链路完整无死角。

方案——精准狙击

“单点爆破”是三月底的初版方案。但5月8日收到“31号前必须完成迁移”的硬性期限后，我知道这条路走不通了——它太依赖预演，而我已经没有预演的时间。

于是在原有架构上升级出第二套方案：精准狙击。

核心优化： 引入双主复制，全程无需改动任何业务服务或连接池配置，也无需在新旧数据库前置 Nginx，彻底消除对预演的依赖。

前置流程不变：新旧业务统一读写 AWS 旧库，GCP 新库作为从库同步。GCP 环境所有服务通过固定域名访问AWS 旧库。

等业务全部迁移完成，先开启双主同步模式，然后将域名解析切换至GCP 新库地址。最后，不再采用“一刀切”的方式，而是对旧数据库的连接进行逐个精准阻断。

双向实时同步是这套方案的核心保障，全程无需大规模预演，可控性更强。

实际落地适配

本平台欧美双节点，在线长连接设备均远不足十万级，流量以心跳为主，日常写压力极低。因此采用双主热备模式，常态仅单库承担读写。上述两套方案，完全贴合该场景。

常规读写分离架构多见于中大型业务，一般会配套专职运维团队做切换预案；

可采用更平和的方式：改造新旧环境所有服务，加切换开关；GCP 环境主库（写库）开级联，作为AWS 环境写库的从库；GCP 环境从库（读库）作为GCP 环境主库的从库。

点击切换开关时，只需分别切换到GCP 环境的读写库即可。至于切换过程中的脏数据修复、写库只读过渡，对运维团队来说都是常规操作。

超大集群多副本分布式架构本人暂无落地经验，不在本文讨论范围内。

最后的一刻

5 月 30 日迁移收尾，欧美节点域名全部切换指向 GCP 新库，校验双主同步无延迟、数据完全追平。

接下来，不依赖脚本，手把手操作。刀尖上的事，只信自己。

KILL 1142421;  — 0.175s
KILL 1148077;  — 0.175s
KILL 1146925;  — 0.175s
KILL 1146796;  — 0.176s
KILL 1142423;  — 0.176s
KILL 1146954;  — 0.175s
KILL 1146949;  — 0.176s
KILL 1146929;  — 0.175s
KILL 1146924;  — 0.182s
...

那些还没有断开的连接，被我一个一个 kill 掉。每一条都在 0.17 秒内响应。

杀完最后一条，我执行了 SHOW FULL PROCESSLIST 和 SHOW SLAVE STATUS。

确认所有连接断开，主从关系解除。AWS 旧库正式停摆。

七年前我建了它，七年后我亲手关了它。