看了能少踩坑，阿里云DTS实施小记

最近在XX客户现场进行了一次RDS数据库灾备实施，使用的是阿里云的数据传输服务。这里先简单介绍一下，数据传输(Data Transmission)是阿里云提供的一种支持RDBMS(关系型数据库)、NoSQL、OLAP等多种数据源之间数据交互的数据服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、跨境数据同步、缓存更新策略等多种业务应用场景，助您构建安全、可扩展、高可用的数据架构。

这次实施要使用的是DTS的数据同步功能，将生产RDS数据同步到另外一个可用区的RDS上。了解过DTS的朋友可能都会觉得比较简单，按部就班将DTS配起来然后进行同步不就得了吗。而事实上我的实施过程并没有那么顺利，下面给大家分享一下实施经验，以让大家以后尽可能地少饶坑。

因为同步的数据涉及到门店的会员数据和会员积分等，所以实施时间定在晚上10点。去到客户现场后，也不是说立刻就可以开干的。客户先等到10点半再开始购买DTS，核实了好几次DTS的规格和价格后终于在立即购买那里点击了鼠标。在同步数据之前我们和客户都认同需要对源RDS进行一次全备，在11点我们对源RDS实例进行物理备份（源RDS有100G左右的数据量，物理备份这里等了40多分钟）。

对源数据库备份完后，客户想在做数据同步作业之前先清空目标RDS，明明可以通过控制台删除数据库，但客户貌似对使用命令行操作有独特的信仰，于是我们创建了RDS的高级权限帐号，用该帐号连进去数据库里面，通过命令行清空了里面的库。这里科普一下，阿里云的DTS需要在目标RDS上创建同步帐号dtssyncwriter，因为创建了高级权限帐号，这个时候控制台无法回到原有使用控制台创建数据库和账号模式，需使用 SQL 命令创建数据库和账号，而事实上发现该帐号原本已存在了。到这里为止，准备工作都做了，接下来按照官方指引配完DTS，预检查并开始同步。

好不容易等到同步完成了，客户发现有两个比较关注的表中多了10多条数据，我们问客户会不会可能在半夜还有新数据的写入？客户坚信门店都已经关门了，绝对不会有人员进店和资料更新的，然后就开始怀疑阿里云DTS是不是不可靠，是不是源和目标RDS会互相同步才导致了数据的增加。如果客户存在这种顾虑和疑问，我们应该绝对肯定的告知客户同步是单向的，不会动原始数据，而事实上当时我们也是这样告知客户的。

还没开始去找多了数据的原因，这个时候来了个乌龙，客户发现刚才同步的这个目标RDS是经典网络的，而其余的RDS都是专有网络，这对后面的通信是有问题的，客户意识到自己选错了目标RDS，这意味着我们之前的工作又要重做了。

客户的环境中还有另外一台目标RDS（专有网络）可用来做数据同步，这个RDS同样是之前使用过的，里面的数据已经没用了。客户对操作已经驾轻就熟了，于是直接重新配置了DTS并进行同步，在等待同步的过程中发现目标RDS上存在和源RDS同名的旧库，在同步之前忘记先删除掉了，更糟糕的是，这个时间刚好碰上源RDS那边正在做设定的计划任务的自动备份，无奈只能硬着头皮让它继续同步祈祷最后能同步成功，这个时候已经是凌晨4点。

硬着头皮同步完，同样的，对比一下比较关注的两个表中的数据，发现目标RDS中只有几条数据，意味着同步不生效，可能的原因有两个，一个是在同步前没有先清空原有的同名旧数据库，另一个是因为当时源RDS正在做自动备份。

洗了一把脸，再来一次。先直接通过控制台删除掉数据库，然后配置DTS，开始同步。这次同步完成后客户又对比了一下数据，发现源和目标RDS相比上次对比有多了一些数据，我们再次告诉客户请相信阿里云的DTS是单向同步的，除非是源RDS在半夜的时候仍然有新数据写入才导致数据增加的。

虽然数据是增加了，在客户确认了源RDS和目标RDS两个比较关注的表中记录数是一致的之后，我们决定找出数据增长的原因，发现客户比较关注的两个表中都有createdtime这个字段，然后用sql命令查找createdtime在0点0分1秒之后的记录，发现的确在凌晨是有新的数据写入，而且数量刚好就是之前对比得出的差值。终于舒了一口气。

最后总结一下，虽然DTS的技术点实施看起来比较简单，但是事实证明结合企业实际情况时也可能会变得复杂。另外，也建议大家在方案涉及的时候考虑风险点和应对措施，在实施前对相关技术了解清楚，在实施时要仔细、按序、彻底，在和客户交流过程中给予客户足够的信心。