使用 TiDB Data Migration 迁移分库分表数据库到 Amazon Aurora

{"value":"#### **概述**\n\n在传统 IT 时代，由于单机数据库的计算能力、存储容量、网络带宽的瓶颈限制，当表数据超过数千万条时，就会面临较严重的性能下降问题，除了提升单机硬件性能之外，常用的解决手段为；增加集中式缓存、数据库读写分离、数据库拆分。\n\n\n\n本文主要关注数据库拆分：其指按照特定的条件和维度，将同一数据库拆分到多个数据库上以达到分布式数据库的效果，变相地降低了单个数据集的大小，本质上是以空间换时间来提升性能。数据库拆分可分为以下两种方式：\n\n\n\n数据库垂直拆分：是指按照业务耦合度，将关联性低的业务表拆分到单独的数据库。做法与所谓单体架构拆分为微服务类似，需要按业务领域进行划分。\n\n\n\n数据库水平拆分：是指将同一个表按一定策略(hash、range)分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，突破性能瓶颈。对于数据库水平拆分，即我们常说的数据库分库分表(Database Sharding)，通常需要借助框架或者中间件实现，具体可以归纳为如下几类：\n\n\n**1.CLIENT 模式：**\n\n借助数据库 Driver 层实现在客户端本地进行分库分表逻辑控制，即客户端直连多个数据库，在本地进行数据的聚合汇总等操作逻辑。代表产品有 ctrip-DAL。\n\n**2. PROXY 模式：**\n\n即一个数据库代理，代理底层的多个数据库，且分库分表逻辑在代理端实现，对客户端透明。代表产品有 MyCat、阿里云 PolarDB-X(原DRDS)。\n\n\n**本质上，分库分表数据库是使用多个数据库+框架或者中间件实现了一个伪分布式数据库**，以解决单机数据库的性能、容量瓶颈问题，但其在使用中存在诸多不便：\n\n\n\n扩容复杂度增加（需要重分布数据）。\n\n分布键选择需要谨慎，很多 Sharding 产品不支持多个分布键、或者不支持随机分布，导致用户不得不使用没有任何业务意义的自增序列来作为分布键。\n\n无法支持复杂查询。跨库 JOIN 性能差，甚至只能按分布键 JOIN，其他字段不支持 JOIN。\n\n分库分表代理中间件存在潜在性能风险。\n\n分布式事务性能较差，甚至不支持分布式事务。\n\nSQL 功能缺失，限制较多，导致应用适配成本巨大。\n\n全局一致性时间点恢复几乎不可实现，不同的数据节点处于不同的状态，没有全局统一的快照管理和恢复机制。\n\n\n\n而在云计算时代涌现出了许多计算与存储分离的云原生数据库架构，其中的代表之一 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 数据库，其实现了一个跨3可用区 6份数据副本的分布式存储系统，数据库卷逻辑上分为 10GB 单位大小，各个分段都分散在庞大的分布式存储队列中。\n\n\n\n如果发生故障，导致一个分段丢失，单个保护组的修复只需要移动大约10GB 的数据，几秒钟即可完成；更重要的是，[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 遵循日志即数据库，通过只将重做日志记录写入存储层，系统可以将网络的 IOPS 减少一个数据量级；同时将数据库系统中最复杂与关键的功能，备份恢复等等也委托给了存储层服务，与运行在类似硬件上的 [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail) for MySQL 相比，[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。\n\n\n\n综上所述，天然生长在分布式存储上的 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 数据库，最高容量支持128TB，完全兼容 MySQL 和 PostgreSQL，在某些场景下5倍于 MySQL 的性能，相对于难以驾驭的以分库分表实现的伪分布式数据库，[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 的优势明显。\n#### **方案说明**\n\n\n\n如果您也困扰于分库分表方案的繁琐复杂，那么可以尝试将您的数据库迁移到 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 数据库，本文将对整个迁移方案和执行步骤进行详细描述：\n\n\n\n**1. 前置说明**\n\n\n\n本文示例中所使用的分库分表源端为Proxy模式，分库分表配置为2个库，每库4张表，其具体的架构以及Schema如下图所示：\n\n\n\n请注意，使用 TiDB DM 迁移，对源端数据库有如下限制：\n\n\n\n源表中必须存在主键，否则 DM 无法迁移。\n\n源表中必须无外键关联，否则 DM 无法迁移。\n\n\n\n**2. 工具介绍**\n\n\n\na. TiDB Data Migration\n\n\n\n本文使用的迁移合表工具为 TiDB Data Migration（简称DM），可通过 TiDB 原生的集群运维工具TiUP完成安装和部署，DM 的介绍如下：\n\n\n\n**TiDB** **Data** **Migration**(DM)是一体化的数据迁移任务管理工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的数据迁移。DM工具旨在降低数据迁移的运维成本。DM 数据迁移任务包含全量数据迁移、增量数据复制两个阶段：\n\n全量数据迁移：从数据源迁移对应表的表结构到 TiDB，然后读取存量数据写入到 TiDB 集群；\n\n\n\n增量数据复制：全量数据迁移完成后，从数据源读取对应的表变更然后写入到 TiDB 集群。\n\n\n\nDM 工具的核心组件如下图所示：\n\n**Block** **&** **allow** **lists**\n\n过滤规则类似于 MySQL replication-rules-db/replication-rules-table，用于过滤或指定只迁移某些数据库或某些表的所有操作。\n\n\n\n**Binlog** **event** **filter**\n\n用于过滤源数据库中特定表的特定类型操作，比如过滤掉表 test.sbtest 的 INSERT 操作或者过滤掉库 test 下所有表的 TRUNCATE TABLE 操作。\n\n\n\n**Table** **routing**\n\n将源数据库的表迁移到下游指定表的路由功能，比如将源数据表 test.sbtest1 的表结构和数据迁移到 TiDB 的表 test.sbtest2。\n\n利用 DM 工具中 Table routing 模块，将上游数据按照配置的规则路由到下游，即可实现将分库分表数据库迁移到 Aurora MySQL。\n\n\n\nb. Amazon Cloud Development Kit\n\n\n\n本文使用**亚马逊云科技** **Cloud** **Development** **Kit**(CDK)一键部署DM工具到亚马逊云科技 EC2，并为您自动创建 DM 集群，实现所谓开箱即用，节省自己搭建所需的时间成本。\n\n\n\nCDK 是一种开源软件开发框架，可让您使用熟悉的编程语言来定义云应用程序资源。预置云应用程序是一个具有挑战性的过程，您需要执行手工操作、编写自定义脚本、维护模板或学习特定领域的语言。亚马逊云科技 CDK 利用编程语言的常见性和表达能力为应用程序建模。CDK 提供名为结构的高级组件，使用经过验证的默认值预置云资源，因此您无需成为专家即可构建云应用程序。亚马逊云科技 CDK 通过 亚马逊云科技 CloudFormation 以安全、可重复的方式预置您的资源。它还支持您编写和分享体现组织要求的自定义结构，帮助您更快启动新项目。\n**3. 迁移方案**\n\n\n如上图所示，该方案的源库为基于某分库分表中间件，其底层为 MySQL数据库，使用 DM 工具将其迁移到 Aurora MySQL 上；本质上就是使用DMWorker 连接到底层的所有分库分表，然后基于所配置的数据路由规则，将所有数据路由到 Aurora MySQL 中的单库单表，来实现迁移，具体的步骤如下：\n\n\n\n使用 CDK 脚本创建 EC2 集群，该 EC2 集群会被创建在默认 VPC 的Public Subnet 中，通过 EC2 UserData 下载 TiUP 来安装 DM 程序，并部署 DM 集群(DMMaster + DMWorker)；\n\n基于分库分表中间件底层的所有MySQL数据库创建 DM Source；\n\n创建基于 DM 数据迁移任务，并且配置路由，实现合库合表；\n\n启动任务，完成全量和增量合库合表数据迁移。\n\n如上图所示，描述为迁移前分库分表的 Schema，以及迁移后在 Aurora中的 Schema。\n\n\n\n了解更多关于 TiDB Data Migration 信息：\n\n[https://github.com/pingcap/dm](https://github.com/pingcap/dm) \n\n了解更多 Amazon Cloud Development Kit 的信息：\n\n[https://aws.amazon.com/cn/cdk/](https://aws.amazon.com/cn/cdk/) \n#### **执行步骤**\n\n\n\n**1.安装所需软件：**\n\n\n\n找到一台 Linux 服务器，安装好 NodeJS、Python3、PIP、CDK、亚马逊云科技 CLI 等程序，同时完成亚马逊云科技 CLI 的配置。具体可以参考[https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)。\n\n下载基于 CDK 实现的 DM 一键部署程序到本地一台 Linux 或者Windows 服务器，下载地址[https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk](https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk)，通过执行下述命令进行下载：\n```\\n\\ngit clone https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk\\n```\n**2.安装所有 Python 的依赖：**\n```\\n\\npip install -r requirements.txt\\n```\n\n打开 config/config.json 文件，进行参数配置：\n\n\n参数解释：\n\nkey_pair: 创建 EC2 服务器的 key_pair，会基于此 key 创建 EC2集群间 SSH 的专用 key。\n\ninstance_num: DM 集群中的 EC2 服务器数量，即1个 Master 节点，其余为 Worker 节点；建议每个分库对应一个 Worker；假设有5台分库，那么5个 Worker + 1个 Master，共计6。\n\ninstance_type：EC2 的实例类型，生产环境的迁移建议使用 M5 系列实例。\n\nebs_volumn_size：EC2 的 EBS 卷大小，如果使用 DM 执行全量迁移，本地会暂存全量导出的数据库文件，需要保证 EBS 卷足够大。\n\ndm_name：DM 集群的 Name。\n\ndm_version：DM 集群的版本。\n**3.执行CDK** **BootStrap：**\n```\\n\\ncdk bootstrap\\n```\n\n**4. 执行 CDK** **Deploy：**\n```\\n\\ncdk deploy —require-approval never\\n```\n增加— require-approval never 参数可以跳过确认步骤。\n\n**5.登录 EC2 查看 DM 集群状态：**\n进入 CloudFormation 控制台，找到 tidm-migration 的 Stack，在右侧 resources 标签下找到 Logical ID为“TiDMInstance00XXXXXX”的 EC2，点击右侧的“Physical ID”跳转到 EC2控制台，查看此 EC2的公网IP。使用 SSH 登录此 EC2，查看 DM 集群状态，并且记录 DMMaster 节点的 IP。\n\n\n\n**6.配置所有分库作为数据源：**\n获取分库的密码，执行如下指令，对密码进行加密，请将”中的字符串替换为您的密码，记住加密后的密码。\n```\\n\\ntiup dmctl encrypt 'abc!@#123'\\n```\n\n\n针对分库创建配置文件 source-sharding.yaml，具体的配置内容如下：\n```\\nsource-id: \\"source-sharding1\\"\\nenable-gtid: false型的数据\\nfrom:\\nhost: \\"database-mysql-57.xxxxxxxxxxxxxx.us-west-2.rds.amazonaws.com\\"\\nuser: \\"admin\\"\\npassword: \\"xxxxxxxxxxxxxxxxxxxxxxxx\\" #此处填写上述步骤中加密之后的密码\\nport: 3306\\n```\n执行下述命令，创建数据源，其中 master-addr 为之前记录的 DMMaster 节点 IP：\n```\\ntiup dmctl --master-addr 172.31.30.29:8261 operate-source create ./source-sharding1.yaml\\n```\n\n执行下述命令，查看数据源是否创建成功：\n```\\ntiup dmctl --master-addr 172.31.30.29:8261 get-config source source-sharding1\\n```\n\n针对所有的 Sharding 分库，依次执行上述步骤，创建所有的数据源。\n**7.创建分库分表任务：**\n\n\n\n创建 task-sharding-merge.yaml，并写入如下内容：\n```\\nname: \\"task-sharding-merge\\"\\ntask-mode: all # 进行全量数据迁移 + 增量数据迁移\\nmeta-schema: \\"dm_meta\\"\\nignore-checking-items: [\\"auto_increment_ID\\"]\\n\\ntarget-database:\\n host: \\"my-aurora.cluster-xxxxxxxxxx.us-west-2.rds.amazonaws.com\\"\\n port: 3306\\n user: \\"admin\\"\\n password: \\"xxxxxxxxxxxxxxxxxxxxxxxxxx\\"\\n\\nmysql-instances:\\n -\\n source-id: \\"source-sharding1\\" # 数据源 ID，可以从数据源配置中获取\\n route-rules: [\\"db-route-rule\\", \\"table-route-rule\\"] # 应用于该数据源的 table route 规则\\n mydumper-config-name: \\"global\\"\\n mydumper-thread: 16 # mydumper 用于导出数据的线程数量\\n loader-thread: 16 # loader 用于导入数据的线程数量\\n syncer-thread: 16 # syncer 用于同步增量数据的线程数量\\n -\\n source-id: \\"source-sharding2\\"\\n route-rules: [\\"db-route-rule\\", \\"table-route-rule\\"]\\n mydumper-config-name: \\"global\\"\\n mydumper-thread: 16 # mydumper 用于导出数据的线程数量\\n loader-thread: 16 # loader 用于导入数据的线程数量\\n syncer-thread: 16 # syncer 用于同步增量数据的线程数量\\n\\n# 所有实例共享的其他通用配置\\nroutes:\\n db-route-rule:\\n schema-pattern: \\"trade_*\\"\\n target-schema: \\"trade\\"\\n table-route-rule:\\n schema-pattern: \\"trade_*\\"\\n table-pattern: \\"t_order_*\\"\\n target-schema: \\"trade\\"\\n target-table: \\"t_order\\"\\n\\nmydumpers:\\n global:\\n extra-args: \\"--no-locks\\"\\n```\n执行下述指令，开始 migration 任务：\n```\\ntiup dmctl --master-addr 172.31.30.29:8261 start-task ./task-shardingmerge.yaml\\n```\n\n执行下述指令，查看 migration 任务状态：\n```\\n\\ntiup dmctl --master-addr 172.31.30.29:8261 query-status\\n```\n\n\n注意，某些云数据库，由于无法获取 superuser 权限，导致 DM 在执行全量数据迁移的时候，会产生报错而退出任务，解决方案为，在任务定义文件中，为 mydumpers 增加”–no-locks” 参数。\n\n#### **总结**\n\n\n\nTiDB Data Migration 作为 PingCAP 开源的一款优秀的数据迁移管理工具，在经过了多个版本的迭代后，已经趋于稳定，可以用作生产级别的数据迁移；而在功能上，除了可以用来支持迁移分库分表的数据库之外，DM 还能支持更多的迁移场景，本文只是抛砖引玉，具体大家可以移步 DM 的官方文档（[https://docs.pingcap.com/zh/tidb-data-migration/v5.3](https://docs.pingcap.com/zh/tidb-data-migration/v5.3)），做更仔细的研究。\n **本篇作者**\n\n**陈超**\n\n**亚马逊云科技迁移解决方案架构师，主要负责亚马逊云科技迁移相关的技术支持工作，同时致力于亚马逊云科技云服务在国内的应用及推广。**\n加入亚马逊云科技之前，曾在阿里巴巴工作8年，历任研发工程师、云计算解决方案架构师等，熟悉传统企业 IT 、互联网架构，在企业应用架构方面有多年实践经验。\n\n[阅读原文](https://aws.amazon.com/cn/blogs/china/use-tidb-data-migration-to-migrate-sub-databases-and-sub-tables-to-aurora/)","render":"<h4><a id=\\"_0\\"></a><strong>概述</strong></h4>\\n<p>在传统 IT 时代，由于单机数据库的计算能力、存储容量、网络带宽的瓶颈限制，当表数据超过数千万条时，就会面临较严重的性能下降问题，除了提升单机硬件性能之外，常用的解决手段为；增加集中式缓存、数据库读写分离、数据库拆分。</p>\n<p>本文主要关注数据库拆分：其指按照特定的条件和维度，将同一数据库拆分到多个数据库上以达到分布式数据库的效果，变相地降低了单个数据集的大小，本质上是以空间换时间来提升性能。数据库拆分可分为以下两种方式：</p>\n<p>数据库垂直拆分：是指按照业务耦合度，将关联性低的业务表拆分到单独的数据库。做法与所谓单体架构拆分为微服务类似，需要按业务领域进行划分。</p>\n<p>数据库水平拆分：是指将同一个表按一定策略(hash、range)分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，突破性能瓶颈。对于数据库水平拆分，即我们常说的数据库分库分表(Database Sharding)，通常需要借助框架或者中间件实现，具体可以归纳为如下几类：</p>\n<p><strong>1.CLIENT 模式：</strong></p>\\n<p>借助数据库 Driver 层实现在客户端本地进行分库分表逻辑控制，即客户端直连多个数据库，在本地进行数据的聚合汇总等操作逻辑。代表产品有 ctrip-DAL。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/99ad5d9d386b4a7ba7a6ae9ffc8372bd_image.png\\" alt=\\"image.png\\" /><br />\\n<strong>2. PROXY 模式：</strong></p>\\n<p>即一个数据库代理，代理底层的多个数据库，且分库分表逻辑在代理端实现，对客户端透明。代表产品有 MyCat、阿里云 PolarDB-X(原DRDS)。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/be54c701f8ae46a381a77269e0e8661e_image.png\\" alt=\\"image.png\\" /></p>\n<p><strong>本质上，分库分表数据库是使用多个数据库+框架或者中间件实现了一个伪分布式数据库</strong>，以解决单机数据库的性能、容量瓶颈问题，但其在使用中存在诸多不便：</p>\\n<p>扩容复杂度增加（需要重分布数据）。</p>\n<p>分布键选择需要谨慎，很多 Sharding 产品不支持多个分布键、或者不支持随机分布，导致用户不得不使用没有任何业务意义的自增序列来作为分布键。</p>\n<p>无法支持复杂查询。跨库 JOIN 性能差，甚至只能按分布键 JOIN，其他字段不支持 JOIN。</p>\n<p>分库分表代理中间件存在潜在性能风险。</p>\n<p>分布式事务性能较差，甚至不支持分布式事务。</p>\n<p>SQL 功能缺失，限制较多，导致应用适配成本巨大。</p>\n<p>全局一致性时间点恢复几乎不可实现，不同的数据节点处于不同的状态，没有全局统一的快照管理和恢复机制。</p>\n<p>而在云计算时代涌现出了许多计算与存储分离的云原生数据库架构，其中的代表之一 Amazon Aurora 数据库，其实现了一个跨3可用区 6份数据副本的分布式存储系统，数据库卷逻辑上分为 10GB 单位大小，各个分段都分散在庞大的分布式存储队列中。</p>\n<p>如果发生故障，导致一个分段丢失，单个保护组的修复只需要移动大约10GB 的数据，几秒钟即可完成；更重要的是，Amazon Aurora 遵循日志即数据库，通过只将重做日志记录写入存储层，系统可以将网络的 IOPS 减少一个数据量级；同时将数据库系统中最复杂与关键的功能，备份恢复等等也委托给了存储层服务，与运行在类似硬件上的 Amazon RDS for MySQL 相比，Amazon Aurora MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。</p>\n<p>综上所述，天然生长在分布式存储上的 Amazon Aurora 数据库，最高容量支持128TB，完全兼容 MySQL 和 PostgreSQL，在某些场景下5倍于 MySQL 的性能，相对于难以驾驭的以分库分表实现的伪分布式数据库，Amazon Aurora 的优势明显。</p>\n<h4><a id=\\"_55\\"></a><strong>方案说明</strong></h4>\\n<p>如果您也困扰于分库分表方案的繁琐复杂，那么可以尝试将您的数据库迁移到 Amazon Aurora 数据库，本文将对整个迁移方案和执行步骤进行详细描述：</p>\n<p><strong>1. 前置说明</strong></p>\\n<p>本文示例中所使用的分库分表源端为Proxy模式，分库分表配置为2个库，每库4张表，其具体的架构以及Schema如下图所示：<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/b593c2ea5fcf40ac992c13d6866dd535_image.png\\" alt=\\"image.png\\" /></p>\n<p>请注意，使用 TiDB DM 迁移，对源端数据库有如下限制：</p>\n<p>源表中必须存在主键，否则 DM 无法迁移。</p>\n<p>源表中必须无外键关联，否则 DM 无法迁移。</p>\n<p><strong>2. 工具介绍</strong></p>\\n<p>a. TiDB Data Migration</p>\n<p>本文使用的迁移合表工具为 TiDB Data Migration（简称DM），可通过 TiDB 原生的集群运维工具TiUP完成安装和部署，DM 的介绍如下：</p>\n<p><strong>TiDB</strong> <strong>Data</strong> <strong>Migration</strong>(DM)是一体化的数据迁移任务管理工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的数据迁移。DM工具旨在降低数据迁移的运维成本。DM 数据迁移任务包含全量数据迁移、增量数据复制两个阶段：</p>\\n<p>全量数据迁移：从数据源迁移对应表的表结构到 TiDB，然后读取存量数据写入到 TiDB 集群；</p>\n<p>增量数据复制：全量数据迁移完成后，从数据源读取对应的表变更然后写入到 TiDB 集群。</p>\n<p>DM 工具的核心组件如下图所示：<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/2e268428498645e5ae122f53d5e526f6_image.png\\" alt=\\"image.png\\" /><br />\\n<strong>Block</strong> <strong>&amp;</strong> <strong>allow</strong> <strong>lists</strong></p>\\n<p>过滤规则类似于 MySQL replication-rules-db/replication-rules-table，用于过滤或指定只迁移某些数据库或某些表的所有操作。</p>\n<p><strong>Binlog</strong> <strong>event</strong> <strong>filter</strong></p>\\n<p>用于过滤源数据库中特定表的特定类型操作，比如过滤掉表 test.sbtest 的 INSERT 操作或者过滤掉库 test 下所有表的 TRUNCATE TABLE 操作。</p>\n<p><strong>Table</strong> <strong>routing</strong></p>\\n<p>将源数据库的表迁移到下游指定表的路由功能，比如将源数据表 test.sbtest1 的表结构和数据迁移到 TiDB 的表 test.sbtest2。</p>\n<p>利用 DM 工具中 Table routing 模块，将上游数据按照配置的规则路由到下游，即可实现将分库分表数据库迁移到 Aurora MySQL。</p>\n<p>b. Amazon Cloud Development Kit</p>\n<p>本文使用<strong>亚马逊云科技</strong> <strong>Cloud</strong> <strong>Development</strong> <strong>Kit</strong>(CDK)一键部署DM工具到亚马逊云科技 EC2，并为您自动创建 DM 集群，实现所谓开箱即用，节省自己搭建所需的时间成本。</p>\\n<p>CDK 是一种开源软件开发框架，可让您使用熟悉的编程语言来定义云应用程序资源。预置云应用程序是一个具有挑战性的过程，您需要执行手工操作、编写自定义脚本、维护模板或学习特定领域的语言。亚马逊云科技 CDK 利用编程语言的常见性和表达能力为应用程序建模。CDK 提供名为结构的高级组件，使用经过验证的默认值预置云资源，因此您无需成为专家即可构建云应用程序。亚马逊云科技 CDK 通过 亚马逊云科技 CloudFormation 以安全、可重复的方式预置您的资源。它还支持您编写和分享体现组织要求的自定义结构，帮助您更快启动新项目。<br />\\n<strong>3. 迁移方案</strong><br />\\n<img src=\\"https://dev-media.amazoncloud.cn/a6864d341b7b4a4487a8695d8b12bf39_image.png\\" alt=\\"image.png\\" /></p>\n<p>如上图所示，该方案的源库为基于某分库分表中间件，其底层为 MySQL数据库，使用 DM 工具将其迁移到 Aurora MySQL 上；本质上就是使用DMWorker 连接到底层的所有分库分表，然后基于所配置的数据路由规则，将所有数据路由到 Aurora MySQL 中的单库单表，来实现迁移，具体的步骤如下：</p>\n<p>使用 CDK 脚本创建 EC2 集群，该 EC2 集群会被创建在默认 VPC 的Public Subnet 中，通过 EC2 UserData 下载 TiUP 来安装 DM 程序，并部署 DM 集群(DMMaster + DMWorker)；</p>\n<p>基于分库分表中间件底层的所有MySQL数据库创建 DM Source；</p>\n<p>创建基于 DM 数据迁移任务，并且配置路由，实现合库合表；</p>\n<p>启动任务，完成全量和增量合库合表数据迁移。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/dd5ef60014f74dc092983f7d3f8a79ac_image.png\\" alt=\\"image.png\\" /><br />\\n如上图所示，描述为迁移前分库分表的 Schema，以及迁移后在 Aurora中的 Schema。</p>\n<p>了解更多关于 TiDB Data Migration 信息：</p>\n<p><a href=\\"https://github.com/pingcap/dm\\" target=\\"_blank\\">https://github.com/pingcap/dm</a></p>\\n<p>了解更多 Amazon Cloud Development Kit 的信息：</p>\n<p><a href=\\"https://aws.amazon.com/cn/cdk/\\" target=\\"_blank\\">https://aws.amazon.com/cn/cdk/</a></p>\\n<h4><a id=\\"_160\\"></a><strong>执行步骤</strong></h4>\\n<p><strong>1.安装所需软件：</strong></p>\\n<p>找到一台 Linux 服务器，安装好 NodeJS、Python3、PIP、CDK、亚马逊云科技 CLI 等程序，同时完成亚马逊云科技 CLI 的配置。具体可以参考<a href=\\"https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html\\" target=\\"_blank\\">https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html</a>。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/1588b7edb2c1443dacfa2dee775e0087_image.png\\" alt=\\"image.png\\" /><br />\\n下载基于 CDK 实现的 DM 一键部署程序到本地一台 Linux 或者Windows 服务器，下载地址<a href=\\"https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk\\" target=\\"_blank\\">https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk</a>，通过执行下述命令进行下载：</p>\\n<pre><code class=\\"lang-\\">\\ngit clone https://github.com/crazyoyo/tidb-dm-autodeploy-bycdk\\n</code></pre>\\n<p><strong>2.安装所有 Python 的依赖：</strong></p>\\n<pre><code class=\\"lang-\\">\\npip install -r requirements.txt\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/cdfdae5b65474f1bac23cac8503ce8ea_image.png\\" alt=\\"image.png\\" /><br />\\n打开 config/config.json 文件，进行参数配置：<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/5265f81ddcb14dec8d671db3b8f36844_image.png\\" alt=\\"image.png\\" /></p>\n<p>参数解释：</p>\n<p>key_pair: 创建 EC2 服务器的 key_pair，会基于此 key 创建 EC2集群间 SSH 的专用 key。</p>\n<p>instance_num: DM 集群中的 EC2 服务器数量，即1个 Master 节点，其余为 Worker 节点；建议每个分库对应一个 Worker；假设有5台分库，那么5个 Worker + 1个 Master，共计6。</p>\n<p>instance_type：EC2 的实例类型，生产环境的迁移建议使用 M5 系列实例。</p>\n<p>ebs_volumn_size：EC2 的 EBS 卷大小，如果使用 DM 执行全量迁移，本地会暂存全量导出的数据库文件，需要保证 EBS 卷足够大。</p>\n<p>dm_name：DM 集群的 Name。</p>\n<p>dm_version：DM 集群的版本。<br />\\n<strong>3.执行CDK</strong> <strong>BootStrap：</strong></p>\\n<pre><code class=\\"lang-\\">\\ncdk bootstrap\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/faad349f334d4e07ab707da48ee88189_image.png\\" alt=\\"image.png\\" /><br />\\n<strong>4. 执行 CDK</strong> <strong>Deploy：</strong></p>\\n<pre><code class=\\"lang-\\">\\ncdk deploy —require-approval never\\n</code></pre>\\n<p>增加— require-approval never 参数可以跳过确认步骤。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/c145ec0ee4a64be3af412f8ed24ba53c_image.png\\" alt=\\"image.png\\" /><br />\\n<strong>5.登录 EC2 查看 DM 集群状态：</strong><br />\\n进入 CloudFormation 控制台，找到 tidm-migration 的 Stack，在右侧 resources 标签下找到 Logical ID为“TiDMInstance00XXXXXX”的 EC2，点击右侧的“Physical ID”跳转到 EC2控制台，查看此 EC2的公网IP。使用 SSH 登录此 EC2，查看 DM 集群状态，并且记录 DMMaster 节点的 IP。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/990d0fc6addf4684abdf167ab2ddd7e4_image.png\\" alt=\\"image.png\\" /></p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/a08e590a1cb5414bb55da67abf56e17b_image.png\\" alt=\\"image.png\\" /><br />\\n<strong>6.配置所有分库作为数据源：</strong><br />\\n获取分库的密码，执行如下指令，对密码进行加密，请将”中的字符串替换为您的密码，记住加密后的密码。</p>\n<pre><code class=\\"lang-\\">\\ntiup dmctl encrypt 'abc!@#123'\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/c06f7eb080444ccd8eb0ee75486b9206_image.png\\" alt=\\"image.png\\" /></p>\n<p>针对分库创建配置文件 source-sharding.yaml，具体的配置内容如下：</p>\n<pre><code class=\\"lang-\\">source-id: &quot;source-sharding1&quot;\\nenable-gtid: false型的数据\\nfrom:\\nhost: &quot;database-mysql-57.xxxxxxxxxxxxxx.us-west-2.rds.amazonaws.com&quot;\\nuser: &quot;admin&quot;\\npassword: &quot;xxxxxxxxxxxxxxxxxxxxxxxx&quot; #此处填写上述步骤中加密之后的密码\\nport: 3306\\n</code></pre>\\n<p>执行下述命令，创建数据源，其中 master-addr 为之前记录的 DMMaster 节点 IP：</p>\n<pre><code class=\\"lang-\\">tiup dmctl --master-addr 172.31.30.29:8261 operate-source create ./source-sharding1.yaml\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/9d6a644597a34d63b623d0b665a59432_image.png\\" alt=\\"image.png\\" /><br />\\n执行下述命令，查看数据源是否创建成功：</p>\n<pre><code class=\\"lang-\\">tiup dmctl --master-addr 172.31.30.29:8261 get-config source source-sharding1\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/524ccaa9d7cf41a19927022f47bca0b4_image.png\\" alt=\\"image.png\\" /><br />\\n针对所有的 Sharding 分库，依次执行上述步骤，创建所有的数据源。<br />\\n<strong>7.创建分库分表任务：</strong></p>\\n<p>创建 task-sharding-merge.yaml，并写入如下内容：</p>\n<pre><code class=\\"lang-\\">name: &quot;task-sharding-merge&quot;\\ntask-mode: all # 进行全量数据迁移 + 增量数据迁移\\nmeta-schema: &quot;dm_meta&quot;\\nignore-checking-items: [&quot;auto_increment_ID&quot;]\\n\\ntarget-database:\\n host: &quot;my-aurora.cluster-xxxxxxxxxx.us-west-2.rds.amazonaws.com&quot;\\n port: 3306\\n user: &quot;admin&quot;\\n password: &quot;xxxxxxxxxxxxxxxxxxxxxxxxxx&quot;\\n\\nmysql-instances:\\n -\\n source-id: &quot;source-sharding1&quot; # 数据源 ID，可以从数据源配置中获取\\n route-rules: [&quot;db-route-rule&quot;, &quot;table-route-rule&quot;] # 应用于该数据源的 table route 规则\\n mydumper-config-name: &quot;global&quot;\\n mydumper-thread: 16 # mydumper 用于导出数据的线程数量\\n loader-thread: 16 # loader 用于导入数据的线程数量\\n syncer-thread: 16 # syncer 用于同步增量数据的线程数量\\n -\\n source-id: &quot;source-sharding2&quot;\\n route-rules: [&quot;db-route-rule&quot;, &quot;table-route-rule&quot;]\\n mydumper-config-name: &quot;global&quot;\\n mydumper-thread: 16 # mydumper 用于导出数据的线程数量\\n loader-thread: 16 # loader 用于导入数据的线程数量\\n syncer-thread: 16 # syncer 用于同步增量数据的线程数量\\n\\n# 所有实例共享的其他通用配置\\nroutes:\\n db-route-rule:\\n schema-pattern: &quot;trade_*&quot;\\n target-schema: &quot;trade&quot;\\n table-route-rule:\\n schema-pattern: &quot;trade_*&quot;\\n table-pattern: &quot;t_order_*&quot;\\n target-schema: &quot;trade&quot;\\n target-table: &quot;t_order&quot;\\n\\nmydumpers:\\n global:\\n extra-args: &quot;--no-locks&quot;\\n</code></pre>\\n<p>执行下述指令，开始 migration 任务：</p>\n<pre><code class=\\"lang-\\">tiup dmctl --master-addr 172.31.30.29:8261 start-task ./task-shardingmerge.yaml\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/fd4305340dec491ba4663f2daa405a14_image.png\\" alt=\\"image.png\\" /><br />\\n执行下述指令，查看 migration 任务状态：</p>\n<pre><code class=\\"lang-\\">\\ntiup dmctl --master-addr 172.31.30.29:8261 query-status\\n</code></pre>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/ad68f9a96f54461ba536dbb3ff9a153c_image.png\\" alt=\\"image.png\\" /><br />\\n注意，某些云数据库，由于无法获取 superuser 权限，导致 DM 在执行全量数据迁移的时候，会产生报错而退出任务，解决方案为，在任务定义文件中，为 mydumpers 增加”–no-locks” 参数。</p>\n<h4><a id=\\"_306\\"></a><strong>总结</strong></h4>\\n<p>TiDB Data Migration 作为 PingCAP 开源的一款优秀的数据迁移管理工具，在经过了多个版本的迭代后，已经趋于稳定，可以用作生产级别的数据迁移；而在功能上，除了可以用来支持迁移分库分表的数据库之外，DM 还能支持更多的迁移场景，本文只是抛砖引玉，具体大家可以移步 DM 的官方文档（<a href=\\"https://docs.pingcap.com/zh/tidb-data-migration/v5.3\\" target=\\"_blank\\">https://docs.pingcap.com/zh/tidb-data-migration/v5.3</a>），做更仔细的研究。<br />\\n<strong>本篇作者</strong></p>\\n<p><strong>陈超</strong></p>\\n<p><strong>亚马逊云科技迁移解决方案架构师，主要负责亚马逊云科技迁移相关的技术支持工作，同时致力于亚马逊云科技云服务在国内的应用及推广。</strong><br />\\n加入亚马逊云科技之前，曾在阿里巴巴工作8年，历任研发工程师、云计算解决方案架构师等，熟悉传统企业 IT 、互联网架构，在企业应用架构方面有多年实践经验。</p>\n<p><a href=\\"https://aws.amazon.com/cn/blogs/china/use-tidb-data-migration-to-migrate-sub-databases-and-sub-tables-to-aurora/\\" target=\\"_blank\\">阅读原文</a></p>\n"}