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

亚马逊云科技
Amazon Aurora
0
0
{"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![image.png](https://dev-media.amazoncloud.cn/99ad5d9d386b4a7ba7a6ae9ffc8372bd_image.png)\n**2. PROXY 模式:**\n\n即一个数据库代理,代理底层的多个数据库,且分库分表逻辑在代理端实现,对客户端透明。代表产品有 MyCat、阿里云 PolarDB-X(原DRDS)。\n![image.png](https://dev-media.amazoncloud.cn/be54c701f8ae46a381a77269e0e8661e_image.png)\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 数据库,其实现了一个跨3可用区 6份数据副本的分布式存储系统,数据库卷逻辑上分为 10GB 单位大小,各个分段都分散在庞大的分布式存储队列中。\n\n\n\n如果发生故障,导致一个分段丢失,单个保护组的修复只需要移动大约10GB 的数据,几秒钟即可完成;更重要的是,Amazon Aurora 遵循日志即数据库,通过只将重做日志记录写入存储层,系统可以将网络的 IOPS 减少一个数据量级;同时将数据库系统中最复杂与关键的功能,备份恢复等等也委托给了存储层服务,与运行在类似硬件上的 Amazon RDS for MySQL 相比,Amazon Aurora MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。\n\n\n\n综上所述,天然生长在分布式存储上的 Amazon Aurora 数据库,最高容量支持128TB,完全兼容 MySQL 和 PostgreSQL,在某些场景下5倍于 MySQL 的性能,相对于难以驾驭的以分库分表实现的伪分布式数据库,Amazon Aurora 的优势明显。\n#### **方案说明**\n\n\n\n如果您也困扰于分库分表方案的繁琐复杂,那么可以尝试将您的数据库迁移到 Amazon Aurora 数据库,本文将对整个迁移方案和执行步骤进行详细描述:\n\n\n\n**1. 前置说明**\n\n\n\n本文示例中所使用的分库分表源端为Proxy模式,分库分表配置为2个库,每库4张表,其具体的架构以及Schema如下图所示:\n![image.png](https://dev-media.amazoncloud.cn/b593c2ea5fcf40ac992c13d6866dd535_image.png)\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![image.png](https://dev-media.amazoncloud.cn/2e268428498645e5ae122f53d5e526f6_image.png)\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![image.png](https://dev-media.amazoncloud.cn/a6864d341b7b4a4487a8695d8b12bf39_image.png)\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![image.png](https://dev-media.amazoncloud.cn/dd5ef60014f74dc092983f7d3f8a79ac_image.png)\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![image.png](https://dev-media.amazoncloud.cn/1588b7edb2c1443dacfa2dee775e0087_image.png)\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![image.png](https://dev-media.amazoncloud.cn/cdfdae5b65474f1bac23cac8503ce8ea_image.png)\n打开 config/config.json 文件,进行参数配置:\n![image.png](https://dev-media.amazoncloud.cn/5265f81ddcb14dec8d671db3b8f36844_image.png)\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![image.png](https://dev-media.amazoncloud.cn/faad349f334d4e07ab707da48ee88189_image.png)\n**4. 执行 CDK** **Deploy:**\n```\n\ncdk deploy —require-approval never\n```\n增加— require-approval never 参数可以跳过确认步骤。\n![image.png](https://dev-media.amazoncloud.cn/c145ec0ee4a64be3af412f8ed24ba53c_image.png)\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![image.png](https://dev-media.amazoncloud.cn/990d0fc6addf4684abdf167ab2ddd7e4_image.png)\n\n![image.png](https://dev-media.amazoncloud.cn/a08e590a1cb5414bb55da67abf56e17b_image.png)\n**6.配置所有分库作为数据源:**\n获取分库的密码,执行如下指令,对密码进行加密,请将”中的字符串替换为您的密码,记住加密后的密码。\n```\n\ntiup dmctl encrypt 'abc!@#123'\n```\n![image.png](https://dev-media.amazoncloud.cn/c06f7eb080444ccd8eb0ee75486b9206_image.png)\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![image.png](https://dev-media.amazoncloud.cn/9d6a644597a34d63b623d0b665a59432_image.png)\n执行下述命令,查看数据源是否创建成功:\n```\ntiup dmctl --master-addr 172.31.30.29:8261 get-config source source-sharding1\n```\n![image.png](https://dev-media.amazoncloud.cn/524ccaa9d7cf41a19927022f47bca0b4_image.png)\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![image.png](https://dev-media.amazoncloud.cn/fd4305340dec491ba4663f2daa405a14_image.png)\n执行下述指令,查看 migration 任务状态:\n```\n\ntiup dmctl --master-addr 172.31.30.29:8261 query-status\n```\n\n![image.png](https://dev-media.amazoncloud.cn/ad68f9a96f54461ba536dbb3ff9a153c_image.png)\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"}
0
目录
关闭
contact-us