阿里云数据库迁移手记

如果没必要，不要去迁移。如果非要迁移，列出服务迁移清单，最后建议两个人完成这个工作，一个操作，一个确认操作。提前通知所有相关开发人员，不要在数据迁移过程中执行数据库变更操作。

为了便于管理，我这里的 10 多个系统（姑且认为十个）共用一个阿里云 RDS 实例。访问量基本最核心的一个占了 95% 以上的访问量。数据库基本上也只这样的比例。我们就把这些系统按照类别分为两类：核心系统和非核心系统。

数据库迁移规划，为当前的非核心系统单独购置一台阿里云 RDS 实例。虽然是非核心业务，但是也不能停机迁移数据库。不停机迁移也很坑的，这个后面会谈到。

数据同步

阿里云的数据同步包括三步：

1. 库表结构迁移
2. 全量迁移
3. 增量迁移

其实还有一步，双向同步，也是坑。如果能停服迁移数据库，就停服迁移数据库。

内部系统迁移尝试

首先迁移内部的 OA 和 CRM 系统，这个比较简单，由于访问量不多，当数据同步完成以后，重复部署服务，生成数据库连接到新数据库即可。

外部非核心大系统

这个系统相对来说是非核心系统中比较核心的，数据库比较到，数据在百 GB 规模。上周末已经启动了同步，但是今天上午不小心删除了同步任务，有 2 个小时的数据不同步，不得已，需要再次创建数据同步任务。新库没有清理数据，好几次全量迁移失败。

外部非核心中系统

还是出问题了。迁移比较顺利，中午迁移完毕以后，下午客户还是报问题了，有两张订单重号（由于业务原因，不能加唯一性限制，但是也可以修，不过最近不再这个系统，能用就不修）。解决方式也比较粗暴，让客户作废这两个订单，再重新开单。

其他非核心种系统

比较简单，比如最小的一个服务只有 不到 条数据记录。

常见问题

数据迁移后，如何保证数据的一致性？
如果服务允许一定时间的服务不可用，建议把旧的数据服务停掉，然后把新的数据服务停掉，然后再启动新服务。如果不允许服务不可用，可以开始数据双向同步，不过问题更多，如果需要双向同步，还是申请停服升级吧。

旧数据库什么时间删除？
建议多保留几天，比如 3 天或者 1 周。

阿里云数据同步服务有一些 bug，不知道我是怎么触发了，只好下个工单，解决方法也比较土，切换到旧版数据同步服务。不太喜欢阿里云的数据管理服务。功能太多，可能自己不是专职 DBA，对它不感冒。

收益

个人没太多收益，做好了是应该的，做不好各个部分都会抱怨。但是从核心系统的稳定性来说，这次数据迁移还是值得的。基本上做到了无感迁移。

后记

由于有一个数据库与核心系统依赖太深，进行跨物理数据库 join 报错了，只好先迁移回来。