摘要：迁移&容灾是数据库的强需求，传统的迁移&容灾技术已经发展多年，随着云时代的来临，在迁移&容灾的使用场景、网络、技术都有很大的变化，如何在云时代下更简单的实现数据库的迁移&容灾，云厂商如何通过新的技术实现弯道超车，本文中阿里云智能数据库产品事业部高级技术专家付大超就为大家分享了阿里云在此领域的技术新进展和应用。
专家简介：付大超（花名：千震），阿里云智能数据库产品事业部高级技术专家，2012年加入阿里巴巴，目前负责DTS&DBS团队和研发，在阿里云提供迁移、同步和容灾的服务，支持阿里巴巴、蚂蚁、阿里云等异地多活单元化架构，曾负责阿里全球最大的HBase集群的开发和维护工作，曾先后工作于IBM、Cisco。
直播回放
链接：https://yq.aliyun.com/live/1048
议题PPT下载，戳这里！
https://yq.aliyun.com/download/3564
本文将主要围绕以下四个方面进行分享：
现状和问题
云时代的机会
阿里云的新进展
应用案例
迁移&容灾现状与问题
2014年，xx银行核心数据库出现故障，导致存取款、网银、ATM等业务全部中断长达37小时。2017年，xx游戏数据库故障，30小时无法服务，数据丢失，导致游戏回档。2018年，xx著名代码托管服务商数据库故障，24小时无法服务。以上这些问题的根源都是数据库。而整体而言，数据库的问题和程序开发是类似的，按照墨菲定律来讲就是只要有出现问题的可能，那么问题就一定会出现。
我们不能和墨菲定律赛跑，因此需要做好数据的迁移和容灾等工作。从业界的两个公开报告分析了数据库出现问题的一些原因。可以看到，在2015年，备份恢复软件收入达到44.49亿美元，这一市场的份额还是比较大的。
国家标准《信息系统灾难恢复规范》可以给大家一些参考，也就是说大家愿意投入的成本和收益是正相关的，花费的钱越多，数据丢失的时间和恢复的市场就会越小。因此，需要在投入成本和数据丢失情况之间进行平衡。上图中右侧是国标中定义的一张表，虽然年代比较久远，但是在今天仍旧有一定的参考意义。
数据复制技术现状
对于迁移和容灾本身而言，都是使用的数据复制技术，包括了逻辑复制和物理复制，这两者之间各有优劣。两者相比而言，逻辑数据复制对于数据库的兼容比较好，实时性好，目的库基本都是可用的，而物理备份目的库却可能是不可用的。
云时代的机会
这里列出了三份涉及到数据库迁移和容灾的Gartner报告，不同报告的金额不同。但是总体来讲，数据库迁移和容灾市场在不断增大，而云上市场更是在翻倍地增长。市场的现状是数据库多种多样，所有的数据都存储在各个数据库系统或者其他存储系统里面，数据是企业的核心资产，一般而言，如果出现了问题都是最高级别的故障，因此可能会造成极大的影响。此外，灾备事故本来发生的就比较多，可能出现数据无法恢复的情况，并且RPO、RTO也可能比较大。而新的变化在于，用户在持续地上云，对于阿里云而言，从2016年到如今，用户处于爆发式增长。而云厂商在快速推进云上数据迁移和灾备服务，而传统软件厂商仍属于领导者，但都在快速云化。
云时代的变化
云时代下，除了数据库迁移和灾备的市场发生了变化之外，其实玩法也变了。场景、网络以及技术都发生了变化。对于场景而言，比如线下网络是隔绝的，但是云上就会出现一些问题，存在很多监管或着合规的要求。还有出海、混合云、多活以及云备份等，私有云自己搭建是比较困难的，但是上云之后可能就会容易很多，可能只需要点击几下鼠标就好了。对于网络而言比较复杂，因为要做网络隔离来保证安全性，因此需要做VPC、专线以及网关等，实现每个用户互不干扰。对于技术而言，很多用户从线下迁移上云存在公网的问题，可能网络质量不是特别好，并且需要解决用户的秒级RPO问题和快照技术问题，还需要保证用户的备份数据集能够提供查询。
云时代的网络架构
可以看到，云服务与阿里云之间、用户本地自建数据库与阿里云之间以及订阅消费与阿里云之间，可能的网络类型包括了公网、私网、VPC、专线和VPN网关，这就为数据库迁移备份带来了很多困难，因为网络是基础设施，如果网络存在很大问题，那么整个服务的性能和稳定性就会遇到非常大的挑战。对于数据迁移而言，最大的不可控因素就是源库和网络。
阿里云的思考
对于阿里云而言，首先需要考虑数据如何流动起来，通过阿里云数据传输服务DTS和数据库备份能够帮助用户搞定迁移和备份问题。
数据高速公路—DTS
数据传输服务(Data Transmission Service，简称DTS) 支持以数据库、大数据、文件为核心的结构化存储产品之间的数据传输，它是一种集数据迁移、数据订阅及实时同步于一体的数据传输服务。DTS是支持增量数据传输的，其增量方法基于日志解析实现，并且支持Oracle、SQL Server、PG、Redis、MongoDB等数据库，这项能力目前在全球都处于领先地位。阿里云DTS应该是公有云上第一个数据传输服务，处于技术的领先地位。并且无论是源端数据库还是目标数据库，DTS都支持友商以及用户本地的数据库。如果用户想要做订阅，比如流计算、搜索、广告等数据库下游业务都需要通过DTS服务来解决问题。
DTS核心模块
如下图所示，DTS整体分为几个模块。为了解决数据同步或者迁移过程中，因为用户的DDL而引起的数据库表结构变更，此时就需要MetaBuilder进行解决。数据解析完成之后放入到DStore里面，变成结构化的数据，其能够支持索引，比如Tag或者Index，DStore类似于简单的数据库，因为其能够支持快速查找。此外，在数据写入的时候还实现了一些Bucket冲突算法等。
日志解析能力
这里介绍一下DTS的DReader基本架构。DReader是插件化的，可插拔的架构，对于源端的各种数据库开发一个插件，将这个插件放到DTS上去之后就能够支持源端数据库到目标数据库的增量数据同步了。
日志解析DReader
对于日志解析而言，存在一定的问题，这里选取几个重点问题进行讲解。第一个问题就是如何构建Schema快照，无论是什么数据库，在解析日志的时候如果源端数据表发生了变更，如何实现对于变更的解析，这就需要将源端数据库的Schema信息和本地适配起来，因此DReader需要Schema的构造和维护能力。第二个关键问题就是大事务、穿插以及回滚事务的解析，这对于MySQL而言比较简单，但对于Oracle而言就会存在很多的问题，而DReader很好地解决了这个问题。
因为Oracle有归档和Redo的功能，DReader可以同时支持这两者，去解析日志的时候需要通过Extractor将其转化成结构化的Record，进而按照事务进行聚合，再实现二进制转化，最终还要做Update回查数据。上图中下侧讲的是断点续传，这里也存在几个问题，当面对大事务的时候，数据存在交叉，正常的安全位点都是记录Commit的位置。而在用户数据库的迁移和同步过程中发现有些任务很奇怪，可能并没有业务数据但是延迟很大，分析其原因是用户存在一些无操作的长事务，只是开启了Begin但是一直没有Commit，这就导致了几方面的问题。一个就是延迟很大，就是一旦重启，因为安全位点很老旧，就会将数据拉倒老旧的安全位点，需要拉取很长一段时间的增量数据，使得数据同步的速度非常慢。另外一点就是很有可能redo等日志已经删除掉了，那么此时就可能无法恢复数据了。因此DReader希望能够判断出来事务是不是一个无操作的事务，这样就能将安全位点移动到合适的位置上来解决相应的问题。对于大事务问题，可能一个事务提交过来100G的数据，那么就需要通过落盘操作将事务解析出来进行进一步处理。这里还有一些其他的问题，比如SQL Server的堆表页迁移和DDL支持问题、PostgreSQL的DDL日志问题以及Redis的resharding日志问题等，还有分布式事务解析问题以及反查对源库影响问题。
幂等同步
幂等同步原理较为简单，但是非常有用。主要就是Insert唯一性冲突的时候，进行Replace语义操作；Update不命中的时候，插入新镜像值；Update唯一性冲突的时候，Delete旧镜像值，插入新镜像值。这一点在DTS中可以做到，数据随意回拉都能够保持一致性。
DTS Any To Any 架构
Any To Any的意思就是任何一个源端数据库到任何一个目标端数据库都只需要开发一次即可。从源端数据到中间是确定的转换，而从中间到目的端数据却是不确定的转换。阿里云DTS为用户提供了转换模型，但是用户也可以自己选择转换逻辑。
分布式解析和同步
如果源端数据库属于分布式架构，采用了分库分表的方式或者使用了集群架构，这种情况下如何实现数据迁移呢？这里支持分布式架构的数据迁移的最关键的问题就是做协同，比如有DDL该怎么办，DDL谁先做谁后做都存在很大的问题。阿里云DTS采用了分布式Raft算法来解决这样的问题。
数据库时光机—DBS
数据库备份服务（Database Backup Service，简称DBS）是为数据库提持续的、可靠的、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，包括企业数据中心、其他云厂商、混合云及公共云。备份主要包括几种环境，公网自建、本地IDC以及ECS自建的数据库，可以支持将数据备份到阿里云OSS和阿里云NAS上。
DBS核心模块
DBS核心模块如下图所示，Full表示全量备份，Inc表示增量备份，这两者都属于逻辑备份，此外DBS还提供了物理备份。
DBS秒级备份
DBS能够实现秒级备份，做到秒级RPO。在做数据库恢复时需要知道想要恢复到哪个库和哪个表，但是因为数据一直在变，难以知道恢复到哪个时间点，而DBS能够帮助用户恢复到任意时间点。
DBS物理备份
对于DBS物理备份而言，需要有一个Agent，比如用户只有本地IDC而没有公网IP，当他想要进行数据备份只需要下载一个Agent即可。Agent能够自动升级，并且一旦启动之后就能够自动汇报心跳，所有的操作都在阿里云上完成，只需要点击几下就能够将全部数据备份或者恢复完成。
双11大屏
下图展示了双11大屏的情况，大屏上展示了实时交易量，那么2135亿这个数字是怎么计算出来的呢？因为全球的交易都发生在不同的地方，想要实时统计并展现这个数字就需要刚才讲到的DTS技术，通过实时增量订阅来获取数据。
阿里云Region单元化
阿里云本身Region单元化的架构都是借助了DTS技术完成的，从而实现了全球同步。
案例1：基于DTS搭建的银泰新零售混合云
举例而言，银泰在全球有几十个商场，之前其数据库都是Oracle，而为了实现“去O”，银泰基于DTS搭建了新零售混合云架构。通过共享Store+源端过滤将银泰专线带宽占用从300Mb->30Mb每秒，源库CPU从40%降低到10%，并且实现了双副本实现秒级容灾。
案例2：某新零售公司异地多活
对于传统架构而言，异地多活是一件比较困难的事情，而如果今天在阿里云上做这件事情就会相对比较简单了。该公司业务上在多地有多套服务，这些服务同时承担业务流量，且服务之间互为备份。借助阿里云，通过双向同步功能，进行各业务中心的数据同步，实现数据全局一致。当某个节点出现异常时，业务秒级切换到其他节点。
案例3：某用户备份数据在线查询
数据库备份DBS和Data Lake Analytics深度合作，发布备份数据在线查询能力，让备份数据“活”起来。无需恢复，用户可以通过SQL语句交互式查询备份数据，查询结果集立刻返回给用户。相对于传统备份，数据在恢复后才有价值，DBS备份数据在线查询对用户最大的价值：快速，在备份验证、归档查询、数据订正、数据提取等场景上，用户可以快速获取备份数据。
案例4：某集成商集成DBS
阿里云的某个用户拥有几十万的SQL Server数据库，想要为用户提供SQL Server能力，这个厂商就将阿里云DTS封装完成之后来提供服务。由此也可以看出，生态伙伴可以借助阿里云以很低的成本做很多事情，最终实现集成商、终端用户、阿里云的三赢。
案例5：某互联网公司-缓存更新业务解耦
用户为了提升读并发，在业务中引入缓存，业务更新请求落在DB，读请求落在缓存。希望在不影响业务的情况下解决缓存更新问题。对于存在依赖关系的上下游业务，希望不影响上游稳定性的情况下，低成本得实现下游业务通知机制。使用阿里云DTS的数据订阅功能，实时获取上游业务的数据库更新数据，更新缓存内容，解决缓存更新问题；触发下游业务逻辑。
案例6：某小视频公司-业务数据实时分析
很多用户会通过自己搭建的Flink集群或者Storm集群实现实时数据分析，想要将这些数据实现增量地写入目的端数据库，通过DTS就能轻松地完成。
案例7：城市大脑
城市大脑是阿里云树立的很好的名片，通过城市大脑帮助很多城市减轻了交通拥堵问题，城市大脑也使用了阿里云的一系列产品，包括DTS、ADB、TSDB、DRDS、DMS等。
