体验 TiDB v6.0.0 之 TiDB 的数据迁移工具 DM-WebUI
作者: 边城元元原文来源:https://tidb.net/blog/87a38392
一、背景
二、DM 准备条件
2.1 了解 DM
2.1.1 DM 组成
组件说明:
1、DM-master
DM-master 负责管理和调度数据迁移任务的各项操作。
保存 DM 集群的拓扑信息
监控 DM-worker 进程的运行状态
控数据迁移任务的运行状态
提供数据迁移任务管理的统一入口
协调分库分表场景下各个实例分表的 DDL 迁移
2、DM-worker
DM-worker 负责执行具体的数据迁移任务。
将 binlog 数据持久化保存在本地
保存数据迁移子任务的配置信息
编排数据迁移子任务的运行
监控数据迁移子任务的运行状态
3、dmctl
dmctl 是用来控制 DM 集群的命令行工具。
创建、更新或删除数据迁移任务
查看数据迁移任务状态
处理数据迁移任务错误
校验数据迁移任务配置的正确性
4、WebUI
DM 可视化管理
2.1.2 Data Migration 架构
1、可以从 DM 集群的任意 master 节点访问 DM WebUI,访问端口与 DM OpenAPI 保持一致,默认为
8261
。访问地址示例:http://{master_ip}:{master_port}/dashboard/
。
2.2 使用 DM 的前提条件
2.2.1 MySQL 协议兼容的数据库
数据库版本要求
MySQL 版本 5.5 ~ 5.7
MySQL 版本 = 8.0 (实验特性)
MariaDB 版本 >= 10.1.2 (实验特性)
表结构的兼容性
检查上游表是否设置了外键。TiDB 不支持外键,如果上游表设置了外键,则返回警告。
(必须)检查字符集是否存在兼容性差异,详见 TiDB 支持的字符集。
(必须)检查上游表中是否存在主键或唯一键约束(从 v1.0.7 版本引入)。
2.2.2 TiDB 的存储空间
TiKV 总节点要有足够的空间(应大于上游数据源的大小 × 副本数 ×2 )
为什么 ×2 呢? 这里主要考虑到下面两个方面:
索引会占据额外的空间
RocksDB 的空间放大效应
2.2.3 开启 WebUI 的配置
为确保 DM WebUI 能正常显示,在使用 DM WebUI 前,确保以下操作或配置已完成:
1、开启 DM OpenAPI 配置:
1)如果你的 DM 集群是通过二进制方式部署的,在该 master 节点的配置中开启 openapi 配置项: openapi = true
2)如果你的 DM 集群是通过 TiUP 部署的,在拓扑文件中添加如下配置:
3) 已经安装好的 dm 集群
2、首次部署 Grafana 时,已正确安装监控相关组件:monitoring_servers 和 grafana_servers。grafana_servers 须按如下进行配置 ( v6.1 版本中已去掉此步骤):
若 grafana_servers 使用了非默认的 IP 和端口,则需要在 WebUI 的 Dashboard 界面填写正确的 IP 和端口。
三、DM 演练说明
本次演练 mysql 环境为 MySQL5.7.26 ( Window 10 )。
3.1 演练图示
本次演练从 mysql3306 单实例 迁移到 TiDB 4000
3.2 上游数据源 Mysql3306
3.2.1 上游 mysql 数据库 test-dm
3.2.2 my.ini 配置
3.2.3 GTID
1、如果上游源数据库存在主从切换,请务必在上游 MySQL 开启 GTID,并在创建上游配置时将 GTID 设为 True,否则数据迁移任务将在主从切换时中断(AWS Aurora 除外);
3.2.4 Relay log
1、当多个迁移任务使用同一个上游时,可能对其造成额外压力。建议开启 relay log 可降低对上游的影响。
2、DM-worker 在运行过程中,会将上游 binlog 实时迁移到本地文件。DM-worker 的 sync 处理单元会实时读取本地 relay log 的 binlog 事件,将这些事件转换为 SQL 语句,再将 SQL 语句迁移到下游数据库。
3、在启用 relay log 功能后,DM-worker 会自动将上游 binlog 迁移到本地配置目录(若使用 TiUP 部署 DM,则迁移目录默认为
<deploy_dir> / <relay_log>
)。自 v5.4.0 版本起,你可以在 DM-worker 配置文件中通过relay-dir
配置本地配置目录,其优先级高于上游数据库的配置文件。
3.2.5 验证上游数据库
3.3 TiDB 集群 cluster111
此处集群名字为以各组件节点数来初始化的名字,建议可根据实际情况起个有意义的辨识度高的名字。
3.3.1 cluster111 拓扑
3.3.2 部署和启动 cluster111
离线安装: https://pingcap.com/zh/product-community/#TiDB 6.0.0-DMR
1)下载安装包 tidb-community-server-v6.0.0-linux-amd64.tar.gz
2)下载 tookit tidb-community-toolkit-v6.0.0-linux-amd64.tar.gz
3.4 部署 DM 集群
3.4.1 DM 拓扑
生成 dm 的拓扑
dm-cluster111 拓扑
3.4.2 部署集群
3.4.3 登录 Dm-WebUI
http://127.0.0.1:8261/dashboard
注意:web-ui 上的 dashboard 上的监控需要设置的 ip 为 master 机器可以访问到的 grafana 的地址和端口
3.5 使用 DM-WebUI 做数据迁移
任务模式 task-mode:
all 全量 + 增量
full 全量
incremental 增量
创建上游数据源配置
后边要多次使用这个上游数据源,所以开启了 relaylog。
3.5.1 测试全量迁移
test_dm(Mysql3306)—>test_dm_full(TiDB 4000) 上游数据库:test_dm(Mysql3306) 已经准备完毕
3.5.1.1 新建 test_dm_full 数据库
3.5.1.2 添加任务 - 基本信息
任务名:task-test-dm-full 原信息:meta_test_dm_full
注意: 这里自定义的存储路径无效,实际将保存在 dm-worker 节点下的 dumped_data.xxx 目录下。 如:/tidb-deploy111/dm-worker-8262/dumped_data.xxx/
3.5.1.3 添加任务 - 上游信息
3.5.1.4 添加任务 - 下游信息
3.5.1.5 添加任务 - 事件过滤
事件过滤器根据具体情况填写(这里可以不填写)
3.5.1.6 添加任务 - 同步规则
必须填写
3.5.1.7 添加任务 - 保存任务并运行
3.5.1.8 任务列表 - 任务完成
3.5.1.9 验证数据完整性
1)Mysql3306 源数据库 test_dm 记录信息
2)TiDB4000 目标数据库 test_dm_full 记录信息
3)源数据与目标数据表和记录数一致。
3.5.2 测试增量迁移
test_dm(Mysql3306)—>test-dm-incremental(TiDB 4000) 上游数据库:test-dm(Mysql3306) 已经准备完毕
注意:incremental: 仅进行增量数据同步,需要指定开始时间或 binlog 位置。
3.5.2.1 新建 test_dm_incremental 数据库
为了让增量使用单独的 dm-work 新建上游数据源 mysql3306-(test_dm)3
3.5.2.2 添加任务 - 基本信息
任务名:task-test-dm-incremental 原信息:meta_test_dm_incremental 存储路径:/tidb/dm/task-test-dm-incremental/dump_data
3.5.2.3 添加任务 - 上游信息
3.5.2.4 添加任务 - 下游信息
3.5.2.5 添加任务 - 事件过滤
事件过滤器根据具体情况填写(这里可以不填写)
3.5.2.6 添加任务 - 同步规则
必须填写
3.5.2.7 添加任务 - 运行
3.5.2.8 验证数据
增量数据按照预期同步到增量库中。
3.5.3 测试全量 + 增量迁移
Mysql(test_dm)—>TiDB(test_dm_all)
3.5.3.1 新建 test_dm_all
3.5.3.2 添加任务 - 基本信息
任务名:task-test-dm-all 原信息:meta_test_dm_all 存储路径:/tidb/dm/task-test-dm-all/dump_data
3.5.3.3 添加任务 - 上游信息
3.5.3.4 添加任务 - 下游信息
3.5.3.5 添加任务 - 事件过滤
事件过滤器根据具体情况填写(这里可以不填写)
3.5.3.6 添加任务 - 同步规则
> 必须填写
提示错误:“test-dm 必须配置到需要 binlog 的日志里”
my.ini
如何复用已经存在的 dm-work
方式 1:停止 dm-work,停止任务、删除上游
方式 2:扩容一个 dm-work
本示例采用扩容一个 dm-work 的方式
3.5.3.7 验证数据一致性
3.5.3.8 对上游数据源(Mysql test_dm)数据做变更测试增量
主要包括:新增表,新增数据,修改数据,删除数据
1、新建表 test_dm
2、下游(目标库 test_dm_all)
注意: 1、如果在任务中没有做事件过滤,那么对 tidb 的表的操作 将会被 源数据库中对应的记录的操作所覆盖。通常这种情况出现在同时写入源和目标库的情况下。 2、如果任务停止,再次启动任务时将从上次同步的时间点继续同步数据。
3.5.3.9 验证增量数据
1)Mysql test_dm 库
2)TiDB test_dm_all 库
3)数据全量 + 增量同步 经验证数据是一致的。
3.5.4 适用场景
从小数据量 MySQL 迁移数据到 TiDB
1)“小数据量”通常指 TB 级别以下
2)直接使用 DM 进行数据同步到 TiDB
从大数据量 MySQL 迁移数据到 TiDB
1)使用 Dumpling 导出全量数据
2)使用 Lightning 导入全量数据
3)使用 DM 持续复制增量数据到 TiDB 需要记录 binlog-name 和 binlog-pos 或 binlog-gtid
从小数据量分库分表 MySQL 合并迁移数据到 TiDB
1)“小数据量”通常指 TB 级别以下
2)直接使用 DM 进行数据同步到 TiDB
从大数据量分库分表 MySQL 合并迁移数据到 TiDB
1)使用 Dumpling 导出全量数据备份
2)适用 Lightning 执行导入多个分库的全量数据到 TiDB 中的特定表
3)使用 DM 进行增量数据迁移
四、DM 诊断
4.1 监控
DM 集群会默认部署一套监控
4.1.1 查看监控的方式
1、http://127.0.0.1:13000/#grafana
2、WebUI (dashboard)
4.2 clinic
clinic 对 dm 的收集使用独立的命令
tiup diag help tiup diag collectdm <dm-clustername>
收集诊断信息
五、注意
5.1 webui 与 dmctl
DM WebUI 中
task
的生命周期有所改变,不建议与 dmctl 同时使用。如果你不习惯 dmctl 可以使用 webui 替代
六、体验过程遇到的小坑
1、 存储路径
每次编辑都会发生变化修改为默认值, 有 强迫症的朋友要每次改为自己指定的路径
2、 上游配置
密码端口填写配置错误要到最后提交任务才会告诉你。(可以优化增加一个验证功能)
3、 在不指定特定表的情况下
如果不需要改变原有表名,下面的空不要填写,下游这里的表名应该留空。注意:不能填写 *
星号 否则没有效果。
七、总结
1、使用 DM 的 WebUI 总体是比较顺畅丝滑,中间遇到了一些问题在官方和社区朋友的帮助下得以解决。
2、特别感谢 PingCAP,感谢社区热心的朋友帮助和支持!
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/d85639fb1b18ec6062d074afd】。文章转载请联系作者。
评论