解读数据传输DTS技术架构及最佳实践

摘要：在阿里云数据库技术峰会上，阿里巴巴高级技术专家付大超(千震)针对于云计算时代最好的数据传输产品阿里云DTS的架构设计、基本原理以及相关的应用场景进行了精彩分享。帮助大家了解了阿里是如何实现异地多活和异构多活的，以及通过DTS轻松实现迁移、双同同步、容灾、订阅的真实案例。

       8月24日，阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们，为大家分享了一线数据库实践经验和技术干货。在本次峰会上，阿里巴巴高级技术专家付大超(千震)针对于云计算时代最好的数据传输产品阿里云DTS的架构设计、基本原理以及相关的应用场景进行了精彩分享。帮助大家了解了阿里是如何实现异地多活和异构多活的，以及通过DTS轻松实现迁移、双同同步、容灾、订阅的真实案例。

以下内容根据演讲嘉宾现场视频以及PPT整理而成。

本次分享的内容主要围绕以下四个部分：

一、DTS技术架构

二、DTS异地&异构多活架构

三、DTS应用案例

四、最佳实践

一、DTS技术架构

DTS产生的背景

       大家下午好，如下图中左侧所示的是几年之前的支付宝发布的一条微博信息，这条微博主要表达的是因为当时杭州的温度很高，导致当时的用电压力比较大，而为了保证居民的正常用电，甚至连阿里巴巴的机房也因此受到限电。而这样的限电却可能会对于阿里的服务、支付宝的服务甚至是阿里云的服务造成影响。在几年之前，阿里巴巴就在思考将服务搬到另外一个地方去，这样即使杭州出现了一些像机房全部断电这样由于不可控因素产生无法提供服务的情况，阿里也依旧能够为全球的用户提供在线服务。所以为了实现上述目标，阿里逐渐开始实现异地多活的场景。

       上图中右侧所展示的是中国人民银行对于数据中心出现的问题的数据统计。可以看出数据中心所出现的问题种类还是比较多的，其中比较典型的就是主机故障、电源故障等。总而言之，就是数据中心会出现各种各样的异常情况导致服务中断。在本质上来说，这样的异常情况是不可以避免的，阿里巴巴在思考该如何解决这些问题的时候就想到了可以通过将数据中心做成异地甚至是全球的架构，这样就可以尽可能地避免因为异常情况导致的服务不可用。比如在双11场景之下，当某一个机房挂掉了，业务也并不会受到影响。为了实现这样的目标，也就产生了DTS这款产品。

DTS简介

       后来发现阿里云也存在着与阿里巴巴同样的需求，因为很多用户需要将自己的数据迁移到阿里云上来去构建自己的数据架构，这时候也会遇到同样的问题。于是DTS这款产品逐渐地从内部开放到外部，开始对外提供服务。所以在今天，阿里云的外部客户能够享受到与阿里内部一样的基础设施和服务。

       目前，DTS产品有这样的几个功能，典型的就是用户上云时需要进行数据迁移，帮助用户将本地机房的数据迁移到阿里云的其他数据库或者用户在ECS上自建的数据库上去。总而言之，DTS产品的目标就是打通整个数据链路。之前的数据在每个产品中，这样相当于是数据孤岛，而通过DTS产品能够消除数据孤岛，将数据链路完全打通，驱动数据自由地流动。除此之外，DTS的功能还有实现长期的数据同步，这一点与数据迁移不同，在长期的数据同步过程中必定会对于可用性、性能以及安全性提出更高的要求，而DTS能够提供长期的数据同步能力。DTS的第三个功能就是实现数据订阅，一些用户在阿里云上拥有很多的数据库，而用户想要将RDS的增量数据订阅回去，更加灵活地构建自己的数据架构。DTS还提供了一点功能就是文件迁移，可以将像SQL以及CSV等以文件的形式导过来。

       通过上述的功能，DTS就能够在应用场景下提供更强大的服务能力。阿里云上的数据库都能够支持DTS，而用户在ECS上自建的数据库以及用户在本地IDC上自建的数据库，包括MySQL、Oracle、SQL Server、PG、MongoDB以及Redis都是能够支持DTS的，而且相对比较特别的是DTS还能够支持增量的能力。而就目前而言，能够支持Oracle、SQL Server、Redis的增量能力的云产品只有DTS能够做到。

DTS发展历史

       DTS的发展经历了很多个阶段，其发展成熟的过程也经历了一定的演变。在今天，DTS能够支持双11这样的场景，其背后是一步一个脚印走下来的，所以每年也都会逐步地实现新的特性。在2012年的时候，DTS就实现了异地冷备；在2013年，实现了同城双活；在2014年实现了异地多活；在2015年的时候，支付宝和天猫国际都开始了全球化的步伐，而这些交易数据是需要进行全球同步的，因为中美之间的链路足够长，所以DTS也实现了中美同步，解决了在上万公里的天然网络延迟的情况下的延时问题以及网络传输的优化问题；最后，在2016年DTS实现了异构双活，也就是实现了两个异构的数据库比如从Oracle到MySQL或从MySQL到OceanBase这样异构场景的双向多活。

DTS架构设计

       上图所展现的是用户维度的DTS产品的架构设计。在最外层所提供了用户可以直接进行操作的控制台，同时也提供了OpenAPI。阿里云在上周上线了OpenAPI的完整文档来帮助用户更好地使用这款产品。用户通过控制台以及OpenAPI这两种途径都可以建立DTS的任务，这样的任务会发到反向代理集群，再到前端集群，最后再下发到核心的工作集群上去。在DTS底层会存在一个任务调度系统，DTS本身是全球服务的，所以可以将命令下发到全球。DTS将能够提供几个功能，比如数据迁移系统就需要解决数据一致性的问题，无论是无主键表还是InnoDB引擎，DTS都能支持用户将数据轻松地迁移到RDS或者自建的ECS甚至是大数据系统上去。除此之外，DTS还提供了数据同步以及数据订阅的功能。而且还提供了上云评估功能，这个功能能够帮助用户更加轻松地评估自己的系统，因为阿里云的用户中有一些用户对于自己的系统并不了解，而且可能并没有专业的DBA，所以这些系统需要一款产品能够为用户提供一些对于系统所存在的问题的建议，比如将数据从Oracle迁移到MySQL可能出现哪些内容不兼容，可能有哪些无主键表，可能有哪些大字段，以及性能如何等。DTS能够为用户的系统提供一个基本的测试报告，让用户可以看到改造成本是什么样的。除了核心功能之外，DTS还会提供一些辅助系统，比如监控系统、运维系统、以及运输系统等。

架构优势：高性能

       接下来分享DTS的架构优势，来帮助大家更加清晰地了解应该在什么样的场景上去应用DTS，并且更好地利用DTS的特性来快速实现业务的快速发展。首先，DTS的第一个架构优势就是高性能，如果用户想要快速地实现异地灾备或者上云，DTS可以帮助用户使得同步性能达到3万多TPS，当然这个数据是在实验场景之下的。阿里云经常会在用户所提交的工单中发现用户的源库和目的库之间的差别很大，这样的情况下往往达不到上述的性能。

       但是DTS会尽可能地提供比测试数据更高的性能，当用户在实际使用的时候就能够感知到即使库写的很大，DTS也能够支持。这是因为DTS内部有一整套通用的解决方案，比如事务冲突检测能够实现并发的事务写入。举个例子，事务1写了表A和表B两张表，另外一个事务2写了表C，还有一个事务3写了表A和表D这两张表，这样的话，事务1和事务3是冲突的，因为他们都写了A这张表，而事务2与他们都不相关，所以事务2是可以和他们并行执行的，而事务1和事务3只能是串行执行的。这个例子非常简单，而在实际情况下却并非如此，因为每个表都有主键、唯一索引以及外键，上述例子只是为了帮助大家进行理解。补充一点：MySQL的事务处理比较简单，但是Oracle数据库的事务则不同，其事务是穿插的，所以在Oracle中实现事务冲突检测就会非常复杂。大家如果做过Oracle的日志解析就会发现其中存在非常大的困难，而目前无论是对于MySQL、Oracle、SQL Server、Redis还是MongoDB，DTS都能够提供支持。

架构优势：高可靠

       DTS的第二个架构优势就是高可靠。云计算本身所具有的特性之一就是可以弹性伸缩，当需要资源的时候就去购买，当不需要的时候就释放掉。而DTS的架构设计上也引入了弹性的思想，在为全球提供服务的时候，任何一个服务节点发生故障时，故障节点的任务自动切换到健康的节点继续完成之前的工作，而应用却是无感知的。

       这时候就会涉及到一些问题，比如断点是如何解决的，另外如果表在全量迁移的过程中挂掉了，是否能连接起来之后从挂掉的地方继续运行，这样尽可能节约时间和计算成本，除此之外还会涉及到无主键表所造成的困难，而这些困难和问题都已经被DTS所解决了。总而言之，DTS能够为用户在使用过程中屏蔽掉这些问题。

基于结构化存储队列的查询和分发技术

       那么为什么DTS在架构上具有一定的领先性呢？一部分原因是DTS所有的增量解析能力都是基于日志实现的，而不是基于查询源库的Select表实现的。阿里云所有的数据库产品的增量能力都是基于日志实现的，这样能够带来一些好处，首先对于源库基本上是没有影响的，而且使得性能足够好，可以实现实时地解析，基本上可以做到秒级，而且大部分的数据同步都在几百毫秒。在做日志解析过程中就需要结构化数据队列这个组件，它所能够实现的功能就是无论使用的是哪一种数据库，都可以将其日志解析过来并且放入到结构化数据队列里面，将其解析成DTS所需要的格式。接下来就可以通过这个结构化数据队列为下游提供服务，比如用户订阅数据、进行数据同步以及未来将会开放的SQL接口的实时查询等。SQL接口的实时查询指的是比如用户想要知道数据库在过往的历史中究竟发生了什么样的变更，这时就可以根据表格的ID查询该表所有的历史变更记录，目前而言这个功能还没有开放出来，后续将会考虑开放。因为这样的架构，所以所有的数据库接入进来都会有天然的实时性。阿里云的DTS是在2015年4月份上线的，而亚马逊AWS在2015年9月份上线了一个类似的产品，但是今天可以不谦虚地说阿里云DTS是目前同类产品中做的最好的。

二、DTS异地&异构多活架构

DTS异地多活

       接下来根据下面这张图分享DTS的异地多活是如何实现的。其实在实现阿里巴巴的异地多活的时候就已经将这套东西整合总结出来了，所以也希望将这套比较复杂的能力赋予公有云的用户，比如阿里云DTS输出了一个双向输出的功能，也就是异地多活的能力，使得用户可以亲身地构建这套东西。在下图所示的场景里面，用户拥有一个A城主库还有一个B城主库，并且希望实现异地双活。

       用户希望既写A城主库又写B城主库，通过DTS就是先建立一个从A到B的正向任务，也就是中间通过一个结构化队列以及DWriter模块实现与所有的数据库之间的事务一致性的写入。这里特别强调在场景上必须实现事务一致性，这是因为像是在天猫或者淘宝下单的时候，订单往往会涉及到几百条SQL以及几个库，而且一个事务可能会涉及到几个表的若干个字段，而其本质上是一个事务，而如果将事务拆开并且同步到B城主库上面去的时候就会发现有些数据当读取过来之后就是不一致的，比如对于一笔订单而言，可能在A城主库中读取的数据发现已经支付，但是在B城中读取出来的数据发现这笔订单还没有支付，这就会产生数据不一致的问题。所以希望在这样的场景下也能够保持事务的一致性，这一点也是非常重要的，否则的话在一些非常严格的场景下会产生非常多的问题，比如像银行的流水业务场景。所以DTS所需要解决的问题中，一个是日志的解析，另外一个就是通用的事务解决方案，这样一来正向的方案就建立完成了，同样的反向方案也能够建立。但是在建立反向方案的时候需要解决防循环的问题，也就是不能出现让从A城主库写的数据到了B城主库然后又回到A城主库这样的循环。而防止循环的方案在DTS的异地多活场景中也已经实现了。

DTS异构多活

       其实在这个场景之下还有一个比较大的问题就是两边数据库都可以写入，如何去判断数据是否一致，当数据出现不一致时如何判断出来，以及在判断出来之后又应该如何去进行修复。而且如果没有这样的修复能力，一旦数据出现了问题，损失将是无法挽回的。在今天，阿里巴巴的淘宝、天猫以及支付宝的交易都是搭建在这样的平台之上的，如果出现数据不一致的情况，将会造成极大的影响和损失。正是因为数据一致的问题非常重要，所以一定要有数据的一致性校验的能力，而在DTS的异地多活解决方案中恰恰拥有这样的能力，能够轻松地校验两端的数据库是否是一致的，并且可以非常轻松地订正表，当出现问题时也可以及时地进行修复。

       在下图所示的场景中，展现的是从Oracle数据库迁移到OceanBase或者MySQL数据库。阿里云的很多政府部门或者银行的客户使用的数据库还是Oracle或者DB2，而这些用户往往也希望借鉴阿里巴巴的架构来实现自己的全球化分布来避免单点问题。而在这样的场景之下如何去支持异构数据呢？今天，阿里云在线上已经能够为用户提供这样的能力，而且在银行业也有实际落地的案例，DTS能够将Oracle数据库中的日志解析出来写给OceanBase，而且在这里面还可以支持DDL功能，比如从Oracle到MySQL可以支持DDL。而如果大家对于Oracle和MySQL比较了解的话就会明白他们两者之间的DDL的差别是非常大的。当然这里并不是说阿里云DTS的异构多活解决方案能够支持所有的DDL，但是对于大多数的DDL而言都是能够支持的。

       在上图所示的场景里面存在着一个非常大的问题，就是用户其实从Oracle到OceanBase之间存在着一个缓慢的过程，所以从Oracle逐渐切入到OceanBase或者MySQL上需要一个灰度的能力。在这个场景中，首先假设有三个用户向A城Oracle中写数据，这时候想要切一个用户到B城上去，这时候就需要DTS提供一个能力来告诉用户这个链路的延时是什么样的，如果延时很小就可以将用户从A城切换到B城，这样就可以逐渐地将所有的用户从A城切换到B城上面去。但是当切换过去之后用户可能还是不放心，因为对于像银行业这样的行业而言，如果没有后备的措施，一旦云端发生问题可能就会出现无法迁回到Oracle上去的风险。所以为了让用户放心，DTS同样也提供了迁回到Oracle的能力。而这个功能的实现也存在着比较大的挑战，因为从MySQL或者OceanBase上迁移回Oracle的过程中，数据库也存在着很大的差异性，这样的差异性就需要DTS异构多活产品来抹平，这款产品同样也会提供全量和增量的校验能力，能够实时地发现数据的不一致情况。当将所有的用户全部切换到B城之后就实现了将用户主要业务迁移到阿里云自主可用的RDS、OceanBase以及PolarDB上去。

案例：阿里异构多活

       之前分享了阿里异地多活的技术实现，实际上，除了技术实现以外，还需要从业务层面进行分析。这里使用淘宝中卖家商品维度的场景为例子进行说明，比如从中心到单元是按照用户的ID，也就是买家的维度去取模分割，这样每个单元都会得到一部分的流量，同时中心也会得到一部分的流量。所以如果单元的数量越多，理论上对于双11的支持能力也就越强。在2015年的双11当天单是卖家商品数据库全天同步的数据量就在PB级别了，而且这套方案不是单实例的，而是整套集群的，高峰时候的增量流量在Gbps级别。当运行的数据架构足够大的时候就会发现往往需要去接数据库的下游，包括实时的计算、分析、搜索以及备份等。而阿里的这套机制也是比较完善的，大家在双11的时候看到的能够实时地捕获订单以及交易额的数据媒体大屏幕上的数据都是来源于DTS的，媒体大屏上的数据是绝对真实的，是直接从生产中获取的，而且能够做到秒级别的刷新，所以订单、消费额以及物流情况基本上都能够实时地转移给媒体显示。

       在这个平台里面，DTS提供了异地多活能力，首先解决了阿里巴巴的单点的问题，除此之外还解决了多下游消费的问题。现在很多公司在进行实时计算的时候是以全量的方式去拉取的源库，比如将全量数据每天定时拉取到Hadoop集群或者ODPS中去并进行实时计算，但是随着业务的逐渐发展，会发现用户所需要拉取的库越来越大，同时给系统造成的压力也越来越大，而且数据拉取的下游也会变多，比如搜索、实时计算等，他们需要DTS这样的产品。只要为他提供一个将日志解析成增量的能力，然后赋予数据库的下游共同消费这些增量的能力，就可以实现只拉取一次，让大家能够多次消费，而且这个过程还不是通过SQL去查询源库，所以对于源库基本没有影响，而与此同时对于下游而言，收益则是非常大的。

案例：阿里云全球化

       除了DTS在阿里的应用场景之外，还有阿里云上的应用场景。在今天很多云计算的用户选择了阿里云的产品，而阿里云能够提供比如像华东、杭州以及新加坡等很多的Region，阿里云目前有十几个Region分布于全球，并且还在快速地扩展之中。阿里云天生就是全球化的架构，而阿里云的志向就是做全球化的云计算服务，可以说是志向高远，所以在进行架构设计的时候就需要去考虑使阿里云的云产品能够实现全球化的架构。

       因为DTS是提供给阿里云自己的产品来实现全球化服务的，而像RDS、ECS上面的数据是需要和中心进行交互的，比如用户购买一个RDS，那么这个RDS实例是如何生产出来的，实例与中心之间如何实现信息的交互的，其中的控制节点又是如何控制流动的，这一套东西其实都是基于DTS所提供的全球化和单元化架构实现的。其实，阿里云和阿里的实现方式还不完全相同，阿里云所实现的是双中心的架构，而阿里目前实现的是单中心的架构，但是单中心有backup，所以无论是这两种方式中的哪一种都是可以支撑交易以及下单业务的，所以DTS架构上的复杂性会更高一些。

       DTS可以支持关系型数据库，也支持大数据，还支持NoSQL以及一些应用领域。所以在场景上来看，DTS支持的范围是非常广泛的。

三、DTS应用案例

       接下来分享一些场景下的DTS应用案例，帮助大家了解在什么样的场景下使用DTS，以及应该如何使用DTS。

案例1：某国内大型商场使用DTS从Oracle不停机迁移到RDS

       下图中所展示的是一个真实的案例，某国内大型商场原本是Oracle的用户，但是他希望将自己的数据迁移到云上来。进行迁移可以选择去购买Oracle的服务，但是这个服务是比较昂贵的，而且也会比较复杂，所以用户希望通过DTS来完成。其实对于DTS而言，在页面上创建这样的一个任务是比较简单的，用户只需要点击几下鼠标就可以实现，也不需要专业顾问去提供实现方案的建议。因为不需要付昂贵的软件采购费用和顾问咨询费用，所以使用DTS进行数据迁移的成本是比较低的，可能仅需要几元钱就能够完成从Oracle不停机地迁移到RDS的工作。

       如上图所示，首先会把Oracle的库表列迁入到RDS上去，然后再将全量数据以及增量数据迁移过去。这个过程需要确保的就是如何保证将全量迁移过程中引入的增量写入到目的库中去，还有Oracle的无主键问题应该如何解决，而这些问题都是比较困难的，单纯依靠用户自己去解决则是比较麻烦的，但是使用DTS就能够方便地解决上述问题。阿里云为用户提供了这样的简单功能，而用户却给阿里云提出了更多的场景，比如还是这个大型商场用户，他们还提出了从Oracle到Oracle的双向迁移能力以及从Oracle到RDS的双向能力，阿里云也为用户提供了这样的能力，不仅仅实现了架构的灵活转换，还为用户节约了大量的成本。

案例2：某游戏公司通过DTS同步到海外实现就近访问

       当今中国的游戏行业蓬勃发展，很多游戏公司开始布局海外市场，并且发展情况良好。很多使用了阿里云的游戏公司也提出了这样的新需求：希望将把游戏数据在中美之间进行同步，把下发的游戏参数信息、购买信息等从中国传给美国或者从美国传回中国。阿里云可以通过DTS的中美同步功能帮助用户实现万公里毫秒级延迟的数据同步能力。很多国内发展比较好的创业公司都使用了DTS的中美同步服务，不仅仅是游戏公司，还包括一些无人机之类的公司也都使用了这样的功能。

案例3：某大型央企通过DTS进行在离线实时同步分析目标用户

       目前一些央企、国企也开始走上了上云之路，只不过对于央企或国企而言，上云的道路可能需要分步骤地完成，比如通过DTS逐步地实现大数据分析，对于央企或国企而言，可能原来在本地并没有搭建自己的大数据平台，而现在希望借助阿里云上比较方便的像MaxCompute等来实现大数据能力，而DTS就能够帮助他们实现这样的目标。因为搭建这样的一个大数据集群本身的成本是非常高的，而使用阿里云却是非常方便的，并且成本也会比较低，只需要按需付费就可以了。通过DTS增量能力可以直接写给MaxCompute或者通过Spark的流式接入写给其下游的计算服务，这样也可以解决知识计算以及流式计算的需求。

案例4：某大型互联网公司通过DTS构建公有云异地多活架构

       大型互联网公司可以通过DTS构建如上图所示的公有云异地多活架构，这个案例的基本内容在前面已经分享了，这里不再赘述。

案例5：某视频类科技公司订阅DTS做缓存更新

       有一些用户在实现自己的互联网架构过程中不可避免地需要使用到缓存，无论是Memcache还是Redis，这些缓存所起到的作用就是帮忙挡一层访问。如果没有缓存层，就难以应对像双11这样的场景。而缓存层也都存在着失效的问题，通过使用DTS的数据订阅功能，实时获取数据库更新数据，就能够更新缓存内容，解决缓存失效的问题，而用户使用和搭建这套架构所需要的成本也比较低。

案例6：某商业银行通过DTS构建私有云的两地三中心容灾架构

       重点分享一下这个案例。应中国人民银行的要求，所有的银行都需要提供“两地三中心”的容灾能力，“两地三中心”也成为了银行的标配。而在这之前，很多的银行曾出现过因为数据库版本升级、数据库运维以及其他原因造成服务不可用的问题，但是对于很多银行而言，是不敢轻易切换目的库的，因为这可能对于银行的业务造成很大的影响。银行不敢切换到目的库的本质原因就是他们无法保证目的库能够正常使用。而通过DTS这款产品能够确保目的库通过异地的两地三中心搭建出来一个备库，使其能够实时使用的并且有效。因为通过文件这种方式无法验证副本集是否是有效的，而DTS却是通过备库与第三方库进行有效性验证。

       上图中的两地是深圳和杭州，杭州有两个机房IDC A和B，深圳有IDC C，这样的情况下需要搭建两地——深圳和杭州，三中心——IDC A、B、C三个机房这样的异地多活的架构。使用下图的这种方案是比较轻松的，因为在同城内部是通过阿里云RDS实现运载的，对于异地的情况可以通过使用DTS实现深圳机房的数据运载，而且RTO或者RPO基本在1秒左右。除此之外，将服务切到杭州去之后还可以通过DTS切回到杭州。而成本也会降低一些，这是因为首先对于同城部分，阿里云RDS已经帮助用户实现了；对于异地的数据库而言，从节省成本的角度，可以自己搭建，当然也可以通过RDS来实现。最重要的一点就是目的端的数据库是实时的、有效的，并且能够提供可靠的在线服务。

       在上述案例中，如果IDC A出现了故障，这时候RDS会去做主备切换，但是服务却不会受影响。如果现在用户100%的流量都写入到杭州，应用端会自动切换到IDC B上来，保证整个服务是可用的。

       如果上述案例中的IDC A和B都挂掉了，也就说整个杭州的机房全部挂掉了，在这样的情况下该如何保证服务的可用性？实际上这时候需要通过查看DTS的界面来看其延时是多少，如果延时很小就可以做一些标准的切换流程，把应用的流量切换到深圳去。这个时候即便是整个杭州的机房全部挂掉了，也能够保证服务的正常运行。刚才提到的RPO是1秒，如果可以做到更好，就可以实现杭州节点中的数据在机房恢复之后还能找回来，只是可能某一秒的数据没有写过来，但是当杭州的节点恢复了，数据还是可以同步到深圳节点去的。

四、最佳实践

       上面分享了DTS的一些使用场景，最后为介绍DTS在使用过程中用户反映比较多的典型问题以及最佳实践。

1.DTS连接不上源库报错，这种报错产生的场景和原因有很多，比如数据库是否开放了可以远程连接的权限，因为一些数据库会限制只允许某些IP进行访问；用户填写的用户名和密码是否是正确的；以及数据库有没有连接到公网。所以在这样的场景上，用户发现DTS连接不上源库就需要自己在另外一台ECS上登录自己的源库，查看是否能够连接上，如果能够连接上，说明目前的网路连接是正常的。而在阿里云所接收的工单中发现很多情况下用户的源库限制了IP访问，因为如果用户使用的是自建的数据库而不是RDS版本的数据库，就会自动地限制只允许某些IP进行访问，这也是出于安全性的考虑。所以建议用户在出现这样问题的时候在另外一台ECS上直接访问源库并查看访问情况。

2.使用DTS迁移上云的过程中，如何将应用切换到RDS上去？其实这样的过程具有非常严格的规范，比如应该怎么去切换数据库。这个过程在这里进行简单说明，首先如果发现DTS的延时很小了，就应该将源库置成Read Only的。除此之外，还需要在源库上将应用的Session全部清除掉，因为如果不清除掉，应用还是可以进行写操作。将Session全部清除掉之后就能够确保应用不会再执行写操作，这个时候再将应用切换到目的端。而有时候因为应用机器规模很大，所以导致切不干净，使得有的应用还在向源端的库进行写入，这样就会导致数据不一致，也就是出现了“双写”的情况，这也是一个值得吸取的经验教训。

3.源库和目的库库名、表名、列名不同，比如源库本地是A库改变成目的库是B库，源库中表名是A表到了目的库的表名称变成了B表。在这种场景上，DTS提供了库、表、列的映射，使得用户可以很方便地去进行映射。

4.源库和目的库都有触发器，很多用户的源库上有触发器，而且想要将源库的数据迁移到目的库上去，所以往往会在目的库上再建同样的触发器。然而，其实目的库的触发器是不用建的，因为源库上的触发器所产生的数据会产生Binlog，而通过DTS进行迁移，源库表中有触发器就不需要再向目的端库新建触发器了，因为DTS已经帮助用户将触发器上产生的数据同步到目的端了。不然如果用户在目的端库上也建立触发器就会报错，因为源库上触发器已经产生了同一条记录，这样就会出现主键冲突，进而导致报错。

5.跨账号迁移的问题，也就是在跨账号进行迁移的时候，用户不知道应该如何迁移。DTS在页面上提供了跨账号迁移的功能，用户可以填写另外一个账号的用户名和密码，实现跨账号的迁移。而阿里云DTS还提供了专业的文档帮助用户实现这样的功能。

6.迁移同步过程中进行了Rename表操作，很多用户在源库上需要做在线的DDL，而做在线DDL的时候，很多工具会产生Rename表，而Rename的表也在迁移的对象里面。比如需要迁移A、B、C三个表，用户将A表Rename成D表，再将D表Rename成C表，这样的过程中D表并不在同步对像里面，所以并不会将其同步到目的端去，因为已经选择了A、B、C表，后来D表才出现，所以D表必然不在同步对象中。而在目的端执行从D Rename成C的时候发现没有D这张表了，所以如果需要做Rename操作，建议用户直接选择将整个库进行迁移。整个迁移就能够将源库上所有的表全部同步过去，这样就不会出现Rename而导致的目的端某个表不存在的问题了。总结而言，这是因为使用开源的工具做了在线DDL导致Rename操作进而导致的比较常见的错误，而这个错误也是值得重视的。

7.主子账号迁移、同步，当公司发展壮大了，就会涉及到很多主子账号的问题。为了解决这个问题就需要用户在使用主子账号做迁移或者同步的时候通过主账号给子账号授权，通过授权确定什么账号可以使用哪一个RDS。

8.迁移和同步过程中有DDL，MySQL到MySQL这种场景是支持DDL的，很多用户会出现在源库上建立了DDL并且还跑到目的库上建了一个DDL的情况，也就是两个库上都建了一个DDL，而这样肯定会出现问题。所以对于MySQL这种场景不需要两边都做DDL，在源库做一个表结构，DTS可以帮助用户同步到目的端去。

9.公共云和金融云之间迁移、同步，在公共云和金融云之间是存在隔离的，因为金融云的隔离级别相对而言比较高。数据可以从公共云到金融云，但是反过来从金融云到公共云却是不可以的。

10.目标库多了一个表increment_trx，这个表实际上是DTS在同步过程中或者增量迁移过程中建的元数据表，这张表为的是解决断点续传问题的，如果还处于数据迁移过程中就不要删除这个表，如果没有DTS任务在运行的时候，就可以删除这个表。

11.用户想要实现A->B->C迁移，以及实现级联同步，之前对于这样的级联迁移或者同步的需求是会进行拦截的，但是现在DTS也开始支持这样的操作了，可以实现级联的迁移和同步。

12.用户在使用数据订阅启动SDK报如下的错误:keep alive error，这表示的意思就是订阅程序连接不上DTS的服务，比如在没有连接公网的时候就会出现这样的错误，所以需要让用户自己的服务能够连接外面的公网。阿里云所提供的服务是在公网上的，未来阿里云也会对订阅功能提供私网服务。

本文为云栖社区原创内容，未经允许不得转载，如需转载请发送邮件至[email protected]