很多的大型业务，有着非常繁杂的业务逻辑，随着上云迁云的趋势，越来越多的数据库需要在迁移和搬迁的路上。那么大型系统的数据库，如何高效稳定的搬迁，就需要研究下细节了。
1、业务评估和技术选型
首先要确定自己的业务有用到多少种产品，以数据库来说，需要知道自己使用了哪些数据库，比如MySQL，Redis等多种不同的数据库。
值得注意的是：
1）不同的云厂商，同一类别的产品，名字可能不同。
比如mongodb，在AWS叫做documentDB，在Azure叫做cosmosDB。 这当中的技术实现也会有些许差别，但总归可以看做一类。
2）相同的类别，但是可能特性和社区版有差异。
比如MySQL的开源分支有Oracle版，percona版，mariadb版本。
Redis也有社区集群和codis集群这种区别。
3） 阿里云企业版的特性
MySQL为例，我们有高度兼容的社区优化版 AliSQL，也有企业版XDB 三节点
Redis 我们也有社区版，和企业版TairDB
这些企业版特性，都是针对社区版功能，做了特性深度改造，同时一般都是由阿里内部长期使用，除了特性上优化，稳定性也是经得起考验。
2、实施过程
在搞清楚对标的产品后，下一步就是要做具体的迁云实施
大规模的搬站，往往不仅仅是数据库的搬站，还包括应用的搬迁。 所以一般都会有一个切换时间，在运维窗口期，统一的把应用和数据库同步切换到云平台。
有些场景特别的复杂，比如多套应用相互有依赖，无法单独剥离，如果无法一起搬迁。 则要考虑分批搬迁，这样就会有一个新的要求。
即： 已经切换的应用，需要走阿里云的数据库链路，同时还要考虑保留一条反向链路，作为兜底回滚。 没有切换的关联应用数据库，则需要走本地只读，或者远程读写访问。
这样的双活场景，能够有效保障切换和没切换的应用，都能正常工作。同时提供兜底回滚方案，避免中间过程的问题。 我们的DTS 双向同步，则能很好的实现这样的逻辑。
3、 实施细节
数据库的搬迁，还存在一些细节，需要大家注意。
首先，不能在迁移的过程中，大规模使用大事务、DDL、热点写等情况。 这些都会带来同步链路的延迟，如果有双活业务，那么需要非常重视，可能导致不一致读，引发业务问题。
其次，我们的双向同步中，只有正向链路具备同步DDL的能力，反向链路只能同步DML。 如果反向链路的源，需要做DDL，则会被忽略。 另外，如果使用了ghostptosc等开源无锁表结构变更的情况，这些工具生产的影子表，因为不会被同步，所以影子表的增量，会导致DTS链路报错。
