看了能少踩坑,阿里云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的技术点实施看起来比较简单,但是事实证明结合企业实际情况时也可能会变得复杂。另外,也建议大家在方案涉及的时候考虑风险点和应对措施,在实施前对相关技术了解清楚,在实施时要仔细、按序、彻底,在和客户交流过程中给予客户足够的信心。

相关推荐