亚马逊AWS官方博客
使用TiDB Data Migration迁移分库分表数据库到Amazon Aurora
一．概述
在传统IT时代，由于单机数据库的计算能力、存储容量、网络带宽的瓶颈限制，当表数据超过数千万条时，就会面临较严重的性能下降问题，除了提升单机硬件性能之外，常用的解决手段为；增加集中式缓存、数据库读写分离、数据库拆分。
本文主要关注数据库拆分：其指按照特定的条件和维度，将同一数据库拆分到多个数据库上以达到分布式数据库的效果，变相地降低了单个数据集的大小，本质上是以空间换时间来提升性能。数据库拆分可分为以下两种方式：
- 数据库垂直拆分：是指按照业务耦合度，将关联性低的业务表拆分到单独的数据库。做法与所谓单体架构拆分为微服务类似，需要按业务领域进行划分。
- 数据库水平拆分：是指将同一个表按一定策略(hash、range)分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，突破性能瓶颈。
对于数据库水平拆分，即我们常说的数据库分库分表(Database Sharding)，通常需要借助框架或者中间件实现，具体可以归纳为如下几类：
- CLIENT模式：借助数据库Driver层实现在客户端本地进行分库分表逻辑控制，即客户端直连多个数据库，在本地进行数据的聚合汇总等操作逻辑。代表产品有ctrip-DAL。
- PROXY模式：即一个数据库代理，代理底层的多个数据库，且分库分表逻辑在代理端实现，对客户端透明。代表产品有MyCat、阿里云PolarDB-X(原DRDS)。
本质上，分库分表数据库是使用多个数据库+框架或者中间件实现了一个伪分布式数据库，以解决单机数据库的性能、容量瓶颈问题，但其在使用中存在诸多不便：
- 扩容复杂度增加（需要重分布数据）。
- 分布键选择需要谨慎，很多Sharding产品不支持多个分布键、或者不支持随机分布，导致用户不得不使用没有任何业务意义的自增序列来作为分布键。
- 无法支持复杂查询。跨库JOIN性能差，甚至只能按分布键JOIN，其他字段不支持JOIN。
- 分库分表代理中间件存在潜在性能风险。
- 分布式事务性能较差，甚至不支持分布式事务。
- SQL功能缺失，限制较多，导致应用适配成本巨大。
- 全局一致性时间点恢复几乎不可实现，不同的数据节点处于不同的状态，没有全局统一的快照管理和恢复机制。
而在云计算时代涌现出了许多计算与存储分离的云原生数据库架构，其中的代表之一Amazon Aurora数据库，其实现了一个跨3可用区 6份数据副本的分布式存储系统，数据库卷逻辑上分为 10GB 单位大小，各个分段都分散在庞大的分布式存储队列中。如果发生故障，导致一个分段丢失，单个保护组的修复只需要移动大约10GB 的数据，几秒钟即可完成；更重要的是，Amazon Aurora 遵循日志即数据库，通过只将重做日志记录写入存储层，系统可以将网络的 IOPS 减少一个数据量级；同时将数据库系统中最复杂与关键的功能，备份恢复等等也委托给了存储层服务，与运行在类似硬件上的 Amazon RDS for MySQL 相比，Amazon Aurora MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。
综上所述，天然生长在分布式存储上的Amazon Aurora数据库，最高容量支持128TB，完全兼容MySQL和PostgreSQL，在某些场景下5倍于MySQL的性能，相对于难以驾驭的以分库分表实现的伪分布式数据库，Amazon Aurora的优势明显。
二．方案说明
如果您也困扰于分库分表方案的繁琐复杂，那么可以尝试将您的数据库迁移到Amazon Aurora数据库，本文将对整个迁移方案和执行步骤进行详细描述：
1. 前置说明
本文示例中所使用的分库分表源端为Proxy模式，分库分表配置为2个库，每库4张表，其具体的架构以及Schema如下图所示：
请注意，使用TiDB DM迁移，对源端数据库有如下限制：
- 源表中必须存在主键，否则DM无法迁移。
- 源表中必须无外键关联，否则DM无法迁移。
2. 工具介绍
a. TiDB Data Migration
本文使用的迁移合表工具为TiDB Data Migration（简称DM），可通过TiDB原生的集群运维工具TiUP完成安装和部署，DM的介绍如下：
TiDB Data Migration(DM)是一体化的数据迁移任务管理工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的数据迁移。DM工具旨在降低数据迁移的运维成本。DM数据迁移任务包含全量数据迁移、增量数据复制两个阶段：
- 全量数据迁移：从数据源迁移对应表的表结构到 TiDB，然后读取存量数据写入到 TiDB 集群；
- 增量数据复制：全量数据迁移完成后，从数据源读取对应的表变更然后写入到 TiDB 集群。
DM工具的核心组件如下图所示：
- Block & allow lists
过滤规则类似于 MySQL replication-rules-db/replication-rules-table，用于过滤或指定只迁移某些数据库或某些表的所有操作。
- Binlog event filter
用于过滤源数据库中特定表的特定类型操作，比如过滤掉表 test.sbtest 的 INSERT 操作或者过滤掉库 test 下所有表的 TRUNCATE TABLE 操作。
- Table routing
将源数据库的表迁移到下游指定表的路由功能，比如将源数据表 test.sbtest1 的表结构和数据迁移到 TiDB 的表 test.sbtest2。
利用DM工具中Table routing模块，将上游数据按照配置的规则路由到下游，即可实现将分库分表数据库迁移到Aurora MySQL。
b. AWS Cloud Development Kit
本文使用AWS Cloud Development Kit(CDK)一键部署DM工具到AWS EC2，并为您自动创建DM集群，实现所谓开箱即用，节省自己搭建所需的时间成本。
CDK 是一种开源软件开发框架，可让您使用熟悉的编程语言来定义云应用程序资源。预置云应用程序是一个具有挑战性的过程，您需要执行手工操作、编写自定义脚本、维护模板或学习特定领域的语言。AWS CDK 利用编程语言的常见性和表达能力为应用程序建模。CDK 提供名为结构的高级组件，使用经过验证的默认值预置云资源，因此您无需成为专家即可构建云应用程序。AWS CDK 通过 AWS CloudFormation 以安全、可重复的方式预置您的资源。它还支持您编写和分享体现组织要求的自定义结构，帮助您更快启动新项目。
3. 迁移方案
如上图所示，该方案的源库为基于某分库分表中间件，其底层为MySQL数据库，使用DM工具将其迁移到Aurora MySQL上；本质上就是使用DMWorker连接到底层的所有分库分表，然后基于所配置的数据路由规则，将所有数据路由到Aurora MySQL中的单库单表，来实现迁移，具体的步骤如下：
- 使用CDK脚本创建EC2集群，该EC2集群会被创建在默认VPC的Public Subnet中，通过EC2 UserData下载TiUP来安装DM程序，并部署DM集群(DMMaster + DMWorker)；
- 基于分库分表中间件底层的所有MySQL数据库创建DM Source；
- 创建基于DM数据迁移任务，并且配置路由，实现合库合表；
- 启动任务，完成全量和增量合库合表数据迁移。
如上图所示，描述为迁移前分库分表的Schema，以及迁移后在Aurora中的Schema。
三．执行步骤
- 安装所需软件：
找到一台Linux服务器，安装好NodeJS、Python3、PIP、CDK、AWS CLI等程序，同时完成AWS CLI的配置。具体可以参考这里。
下载基于CDK实现的DM一键部署程序到本地一台Linux或者Windows服务器，下载地址https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk，通过执行下述命令进行下载：
git clone https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk
- 安装所有Python的依赖：
pip install -r requirements.txt
打开config/config.json文件，进行参数配置：
参数解释：
key_pair: 创建EC2服务器的key_pair，会基于此key创建EC2集群间SSH的专用key。
instance_num: DM集群中的EC2服务器数量，即1个Master节点，其余为Worker节点；建议每个分库对应一个Worker；假设有5台分库，那么5个Worker + 1个Master，共计6。
instance_type：EC2的实例类型，生产环境的迁移建议使用M5系列实例。
ebs_volumn_size：EC2的EBS卷大小，如果使用DM执行全量迁移，本地会暂存全量导出的数据库文件，需要保证EBS卷足够大。
dm_name：DM集群的Name。
dm_version：DM集群的版本。
- 执行CDK BootStrap：
cdk bootstrap
- 执行CDK Deploy：
cdk deploy —require-approval never
增加—require-approval never参数可以跳过确认步骤。
- 登录EC2查看DM集群状态：
进入CloudFormation控制台，找到tidm-migration的Stack，在右侧resources标签下找到Logical ID为“TiDMInstance00XXXXXX”的EC2，点击右侧的“Physical ID”跳转到EC2控制台，查看此EC2的公网IP。使用SSH登录此EC2，查看DM集群状态，并且记录DMMaster节点的IP。
- 配置所有分库作为数据源：
获取分库的密码，执行如下指令，对密码进行加密，请将”中的字符串替换为您的密码，记住加密后的密码。
tiup dmctl encrypt 'abc!@#123'
针对分库创建配置文件source-sharding.yaml，具体的配置内容如下：
执行下述命令，创建数据源，其中master-addr为之前记录的DMMaster节点IP：
执行下述命令，查看数据源是否创建成功：
针对所有的Sharding分库，依次执行上述步骤，创建所有的数据源。
- 创建分库分表任务：
创建task-sharding-merge.yaml，并写入如下内容：
执行下述指令，开始migration任务：
执行下述指令，查看migration任务状态：
注意，某些云数据库，由于无法获取superuser权限，导致DM在执行全量数据迁移的时候，会产生报错而退出任务，解决方案为，在任务定义文件中，为mydumpers增加”–no-locks”参数。
四.总结
TiDB Data Migration作为PingCAP开源的一款优秀的数据迁移管理工具，在经过了多个版本的迭代后，已经趋于稳定，可以用作生产级别的数据迁移；而在功能上，除了可以用来支持迁移分库分表的数据库之外，DM还能支持更多的迁移场景，本文只是抛砖引玉，具体大家可以移步DM的官方文档，做更仔细的研究。