TIDB数据迁移
环境准备
MySQL环境准备
MySQL测试数据库
Mysql 官方提供了了一套名为:Employees Sample Database 的测试库(该测试库含有6个表,总计4百万数据记录)
表结构
导入数据
下载后解压
test_db-master.zip
,然后登录 mysql 导入即可
1 | mysql -u root -p < employees.sql |
验证是否成功
1 | mysql -u root -p < test_employees_md5.sql |
下载安装TiDB工具包
安装包位置在
https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz
- {version}:为 Dumpling 的版本号,可以通过 Dumpling Release 查看当前已发布版本
检查最新版本
通过 Dumpling Release 查看当前已发布版本,检查发现Dumpling当前版本是
4.0.11
下载tidb-toolkit
1 | 下载工具包 |
DM数据迁移
TiUP DM 组件简介
TiDB Data Migration (DM) 是一体化的数据迁移任务管理工具,支持从与 MySQL 协议兼容的数据库(MySQL、MariaDB、Aurora MySQL)到 TiDB 的数据迁移,DM 工具旨在降低数据迁移的运维成本。
基本功能
Block & allow lists
上游数据库实例表的黑白名单过滤规则,可以用来过滤或者只迁移某些
database/table
的所有操作。
Block & Allow Lists 的过滤规则类似于 MySQL replication-rules-db
/replication-rules-table
,用于过滤或指定只迁移某些数据库或某些表的所有操作。
1 | block-allow-list: # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。 |
do-dbs
:要迁移的库的白名单,类似于 MySQL 中的replicate-do-db
。ignore-dbs
:要迁移的库的黑名单,类似于 MySQL 中的replicate-ignore-db
。do-tables
:要迁移的表的白名单,类似于 MySQL 中的replicate-do-table
。ignore-tables
:要迁移的表的黑名单,类似于 MySQL 中的replicate-ignore-table
。
以上参数值以
~
开头时均支持使用正则表达式来匹配库名、表名。
Binlog event filter
Binlog event filter 是比迁移表黑白名单更加细粒度的过滤规则,可以指定只迁移或者过滤掉某些
schema / table
的指定类型 binlog,比如INSERT
、TRUNCATE TABLE
。
Binlog Event Filter 用于过滤源数据库中特定表的特定类型操作,比如过滤掉表 test
.sbtest
的 INSERT
操作或者过滤掉库 test
下所有表的 TRUNCATE TABLE
操作。
1 | filters: |
schema-pattern
/table-pattern
:对匹配上的上游 MySQL/MariaDB 实例的表的 binlog events 或者 DDL SQL 语句通过以下规则进行过滤。events
:binlog events 数组,仅支持从以下Event
中选择一项或多项。Event 分类 解释 all 代表包含下面所有的 events all dml 代表包含下面所有 DML events all ddl 代表包含下面所有 DDL events none 代表不包含下面所有 events none ddl 代表不包含下面所有 DDL events none dml 代表不包含下面所有 DML events insert DML insert DML event update DML update DML event delete DML delete DML event create database DDL create database event drop database DDL drop database event create table DDL create table event create index DDL create index event drop table DDL drop table event truncate table DDL truncate table event rename table DDL rename table event drop index DDL drop index event alter table DDL alter table event sql-pattern
:用于过滤指定的 DDL SQL 语句,支持正则表达式匹配,例如上面示例中的"^DROP\\s+PROCEDURE"
。
Table routing
Table routing 提供将上游 MySQL/MariaDB 实例的某些表迁移到下游指定表的功能。
Table Routing 是将源数据库的表迁移到下游指定表的路由功能,比如将源数据表 test.sbtest1
的数据同步到 TiDB 的表 test.sbtest2
。它也是分库分表合并迁移所需的一个核心功能。
1 | routes: |
使用限制
数据库版本
- 5.5 < MySQL 版本 < 8.0
- MariaDB 版本 >= 10.1.2
DDL 语法兼容性
目前,TiDB 部分兼容 MySQL 支持的 DDL 语句。因为 DM 使用 TiDB parser 来解析处理 DDL 语句,所以目前仅支持 TiDB parser 支持的 DDL 语法
DM 遇到不兼容的 DDL 语句时会报错。要解决此报错,需要使用 dmctl 手动处理,要么跳过该 DDL 语句,要么用指定的 DDL 语句来替换它
TiUP安装 DM组件
安装TiUP DM 组件
1 | tiup install dm |
更新 TiUP DM 组件
如果已经安装,则更新 TiUP DM 组件至最新版本:
1 | tiup update --self && tiup update dm |
预期输出
Update successfully!
字样。
TiUP部署 DM组件
编辑初始化配置
需要根据不同的集群拓扑,编辑 TiUP 所需的集群初始化配置文件。
新建一个配置文件
topology.yaml
,部署 1 个 DM-master、1个 DM-worker 的配置如下
1 | vi topology.yaml |
1 | global: |
注意:
- 如果不需要确保 DM 集群高可用,则可只部署 1 个 DM-master 节点,且部署的 DM-worker 节点数量不少于上游待迁移的 MySQL/MariaDB 实例数。
- 如果需要确保 DM 集群高可用,则推荐部署 3 个 DM-master 节点,且部署的 DM-worker 节点数量大于上游待迁移的 MySQL/MariaDB 实例数(如 DM-worker 节点数量比上游实例数多 2 个)。
部署命令格式
通过 TiUP 进行集群部署可以使用密钥或者交互密码方式来进行安全认证:
- 如果是密钥方式,可以通过
-i
或者--identity_file
来指定密钥的路径; - 如果是密码方式,可以通过
-p
进入密码交互窗口; - 如果已经配置免密登录目标机,则不需填写认证。
1 | tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] |
以上部署命令中:
- 通过 TiUP DM 部署的集群名称为
dm-test
。 --user root
:通过 root 用户登录到目标主机完成集群部署,该用户需要有 ssh 到目标机器的权限,并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。-i
及-p
:非必选项,如果已经配置免密登录目标机,则不需填写,否则选择其一即可。-i
为可登录到目标机的 root 用户(或--user
指定的其他用户)的私钥,也可使用-p
交互式输入该用户的密码。
预期日志结尾输出会有
Deployed cluster
dm-testsuccessfully
关键词,表示部署成功。
检查最新版本DM组件
部署版本为
${version}
,可以通过执行tiup list dm-master
来查看 TiUP 支持的最新版本
1 | tiup list dm-master |
我们发现最新版本是v2.0.1
执行部署命令
1 | tiup dm deploy dm-test 2.0.1 ./topology.yaml --user root -p |
出现如下界面,选择y继续,输入密码后继续安装
继续安装后,安装完成后输出
deployed successfully
代表安装完成
TiUP 查看集群情况
TiUP 支持管理多个 DM 集群,该命令会输出当前通过 TiUP DM 管理的所有集群信息,包括集群名称、部署用户、版本、密钥信息等
1 | tiup dm list |
检查部署的 DM 集群
执行如下命令检查
dm-test
集群情况
1 | tiup dm display dm-test |
预期输出包括 dm-test
集群中实例 ID、角色、主机、监听端口和状态(由于还未启动,所以状态为 Down/inactive)、目录信息。
启动集群
预期结果输出
Started cluster
dm-testsuccessfully
表示启动成功。
1 | tiup dm start dm-test |
验证集群运行状态
在输出结果中,如果 Status 状态信息为
Up
,说明集群状态正常。
1 | tiup dm display dm-test |
安装dmctl 运维组件
dmctl 是用来运维 DM 集群的命令行工具,支持交互模式和命令模式。
检查dmctl最新版本
通过如下命令可用查看
dmctl
版本列表
1 | tiup list dmctl |
我们发现 最新版本是
v2.0.1
安装dmctl组件
通过如下命令可用安装dmctl组件,冒号后面是需要安装的版本号
1 | tiup install dmctl:v2.0.1 |
使用 DM 迁移数据
需要的权限
- SELECT
- RELOAD
- LOCK TABLES
- REPLICATION CLIENT
- REPLICATION SLAVE
MySQL服务授权
1 | GRANT SELECT,RELOAD,LOCK TABLES,REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO 'tidb'@'%'; |
打开mysql的binlog
因为DM同步需要MySQL开启binlog日志,修改my.cnf配置文件,并重启
1 | [mysqld] |
MySQL检查
1 | SHOW VARIABLES LIKE '%server_id%'; |
加密数据库密码
在 DM 相关配置文件中,推荐使用经 dmctl 加密后的密码,对于同一个原始密码,每次加密后密码不同。
1 | tiup dmctl -encrypt 'tidb' |
加密后的密码是:
iCFVQcMlR8CAqYMMuLEHDkBnwhd4
检查集群信息
使用 TiUP 部署 DM 集群后,相关配置信息如下:
- DM 集群相关组件配置信息
组件 | 主机 | 端口 |
---|---|---|
dm_worker | 192.168.64.152 | 8262 |
dm_master | 192.168.64.152 | 8261 |
- 上下游数据库实例相关信息
数据库实例 | 主机 | 端口 | 用户名 | 加密密码 |
---|---|---|---|---|
上游 MySQL | 172.16.44.47 | 3306 | tidb | iCFVQcMlR8CAqYMMuLEHDkBnwhd4 |
下游 TiDB | 192.168.64.152 | 4000 | root |
创建数据源
将 MySQL 的相关信息写入到
mysql.yaml
中
1 | vi mysql.yaml |
1 | # MySQL1 Configuration. |
MySql数据源加入到DM集群
在终端中执行下面的命令,使用
tiup dmctl
将 MySQL 的数据源配置加载到 DM 集群中:
1 | tiup dmctl --master-addr 192.168.64.152:8261 operate-source create mysql.yaml |
出现如下界面返回
true
表示添加到集群成功
配置任务
假设需要将 MySQL实例的
employees
库的 所有 表以全量+增量的模式迁移到下游 TiDB 的employees
库 编辑任务配置文件sync_task.yaml
1 | vi sync_task.yaml |
1 | # 任务名,多个同时运行的任务不能重名。 |
MySQL 实例配置前置检查
为了提前发现数据迁移任务的一些配置错误,DM 中增加了前置检查功能:
- 启动数据迁移任务时,DM 自动检查相应的权限和配置。
check-task
命令用于对上游 MySQL 实例配置是否满足 DM 要求进行前置检查。
1 | tiup dmctl --master-addr 192.168.64.152:8261 check-task sync_task.yaml |
如果出现返回结果是true表示检查成功
开启任务
使用
tiup dmctl
执行以下命令启动数据迁移任务。其中,sync_task.yaml
是之前编辑的配置文件。
1 | tiup dmctl --master-addr 192.168.64.152:8261 start-task sync_task.yaml |
返回结果为true表示启动成功
查询任务
如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息,可使用
tiup dmctl
执行以下命令进行查询:
1 | tiup dmctl --master-addr 192.168.64.152:8261 query-status |
query-status
命令的查询结果、任务状态与子任务状态
查询迁移详情
1 | tiup dmctl --master-addr 192.168.64.152:8261 query-status tidb_sync |
任务详情如下
同步文本详情如下
1 | { |
检查全量同步
登录TIDB
登录TiDB 查看数据库是否同步
1 | mysql -u root -h 192.168.64.152 -P 4000 -p |
查看employees数据库
1 | show databases; |
我们发现数据库已经同步
测试增量同步
插入MySQL数据
部门表插入一条数据
1 | INSERT INTO `departments`(dept_no,dept_name)VALUES('d010','test dept'); |
更新MySQL数据
将
dept_emp
中的d001
改为d010
1 | UPDATE dept_emp SET dept_no='d010' WHERE dept_no='d001'; |
共 20211 行受到影响
查看DM的任务状态
1 | tiup dmctl --master-addr 192.168.64.152:8261 query-status tidb_sync |
“synced”: false正在同步
稍等后在进行查看任务状态,发现已经同步完成
检查增量同步数据
登录MySQL后检查MySQL中的数据是否同步到TiDB
1 | mysql -u root -h 192.168.64.152 -P 4000 -p |
我们发现
d010
的更新数据都已经同步过来了
DM的其他操作
暂停数据迁移任务
pause-task
命令用于暂停数据迁移任务。有关
pause-task
与stop-task
的区别如下
- 使用
pause-task
仅暂停迁移任务的执行,但仍然会在内存中保留任务的状态信息等,且可通过query-status
进行查询;使用stop-task
会停止迁移任务的执行,并移除内存中与该任务相关的信息,且不可再通过query-status
进行查询,但不会移除已经写入到下游数据库中的数据以及其中的 checkpoint 等dm_meta
信息。 - 使用
pause-task
暂停迁移任务期间,由于任务本身仍然存在,因此不能再启动同名的新任务,且会阻止对该任务所需 relay log 的清理;使用stop-task
停止任务后,由于任务不再存在,因此可以再启动同名的新任务,且不会阻止对 relay log 的清理。 pause-task
一般用于临时暂停迁移任务以排查问题等;stop-task
一般用于永久删除迁移任务或通过与start-task
配合以更新配置信息。
1 | tiup dmctl --master-addr 192.168.64.152:8261 pause-task tidb_sync |
恢复数据迁移任务
resume-task
命令用于恢复处于Paused
状态的数据迁移任务,通常用于在人为处理完造成迁移任务暂停的故障后手动恢复迁移任务。
1 | tiup dmctl --master-addr 192.168.64.152:8261 resume-task tidb_sync |
停止数据迁移任务
stop-task
命令用于停止数据迁移任务
1 | tiup dmctl --master-addr 192.168.64.152:8261 stop-task tidb_sync |
Dumpling数据迁移
Dumpling导出数据
Dumpling工具简介
Dumpling
是使用 go 开发的数据备份工具,项目地址可以参考Dumpling
。Dumpling命令参数列表
主要选项 | 用途 | 默认值 |
---|---|---|
-V 或 –version | 输出 Dumpling 版本并直接退出 | |
-B 或 –database | 导出指定数据库 | |
-T 或 –tables-list | 导出指定数据表 | |
-f 或 –filter | 导出能匹配模式的表,语法可参考 table-filter | *.* (导出所有库表) |
–case-sensitive | table-filter 是否大小写敏感 | false,大小写不敏感 |
-h 或 –host | 连接的数据库主机的地址 | "127.0.0.1" |
-t 或 –threads | 备份并发线程数 | 4 |
-r 或 –rows | 将 table 划分成 row 行数据,一般针对大表操作并发生成多个文件。 | |
-L 或 –logfile | 日志输出地址,为空时会输出到控制台 | "" |
–loglevel | 日志级别 {debug,info,warn,error,dpanic,panic,fatal} | info |
–logfmt | 日志输出格式 {text,json} | text |
-d 或 –no-data | 不导出数据,适用于只导出 schema 场景 | |
–no-header | 导出 csv 格式的 table 数据,不生成 header | |
-W 或 –no-views | 不导出 view | true |
-m 或 –no-schemas | 不导出 schema,只导出数据 | |
-s 或–statement-size | 控制 INSERT SQL 语句的大小,单位 bytes |
|
-F 或 –filesize | 将 table 数据划分出来的文件大小,需指明单位(如 128B , 64KiB , 32MiB , 1.5GiB ) |
|
–filetype | 导出文件类型(csv/sql) | sql |
-o 或 –output | 导出文件路径 | "./export-${time}" |
-S 或 –sql | 根据指定的 sql 导出数据,该选项不支持并发导出 | |
–consistency | flush: dump 前用 FTWRL snapshot: 通过 TSO 来指定 dump 某个快照时间点的 TiDB 数据 lock: 对需要 dump 的所有表执行 lock tables read 命令 none: 不加锁 dump,无法保证一致性 auto: 对 MySQL 使用 –consistency flush;对 TiDB 使用 –consistency snapshot |
auto |
–snapshot | snapshot tso,只在 consistency=snapshot 下生效 | |
–where | 对备份的数据表通过 where 条件指定范围 | |
-p 或 –password | 连接的数据库主机的密码 | |
-P 或 –port | 连接的数据库主机的端口 | 4000 |
-u 或 –user | 连接的数据库主机的用户名 | root |
–dump-empty-database | 导出空数据库的建库语句 | true |
–ca | 用于 TLS 连接的 certificate authority 文件的地址 | |
–cert | 用于 TLS 连接的 client certificate 文件的地址 | |
–key | 用于 TLS 连接的 client private key 文件的地址 | |
–csv-delimiter | csv 文件中字符类型变量的定界符 | '"' |
–csv-separator | csv 文件中各值的分隔符 | ‘,’ |
–csv-null-value | csv 文件空值的表示 | "\N" |
–escape-backslash | 使用反斜杠 (\ ) 来转义导出文件中的特殊字符 |
true |
–status-addr | Dumpling 的服务地址,包含了 Prometheus 拉取 metrics 信息及 pprof 调试的地址 | ":8281" |
–tidb-mem-quota-query | 单条 dumpling 命令导出 SQL 语句的内存限制,单位为 byte。对于 v4.0.10 或以上版本,若不设置该参数,默认使用 TiDB 中的 mem-quota-query 配置项值作为内存限制值。对于 v4.0.10 以下版本,该参数值默认为 32 GB |
34359738368 |
–params | 为需导出的数据库连接指定 session 变量,可接受的格式: "character_set_client=latin1,character_set_connection=latin1" |
导出需要的权限
- SELECT
- RELOAD
- LOCK TABLES
- REPLICATION CLIENT
创建用户并授权
1 | #创建tidb用户密码是 tidb并授权外部所以IP可以访问 |
验证数据库
1 | mysql -u tidb -h 172.16.44.47 -p |
导出sql文件
Dumpling 默认导出数据格式为 sql 文件。也可以通过设置
--filetype sql
导出数据到 sql 文件:
1 | ./bin/dumpling -h 172.16.44.47 -P 3306 -B employees -u tidb -p tidb --filetype sql --threads 10 -o /tmp/test -F 256MiB |
执行命令后从mysql中导出了文件
查看导出文件
1 | cd /tmp/test/ ; ll |
TiDB Lightning导入数据
TiDB Lightning简介
TiDB Lightning 是一个将全量数据高速导入到 TiDB 集群的工具。
TiDB 使用场景
TiDB Lightning 有以下两个主要的使用场景:
- 一是大量新数据的快速导入;
- 二是全量备份数据的恢复。
目前,Lightning 支持 Dumpling 或 CSV 输出格式的数据源。
你可以在以下两种场景下使用 Lightning:
- 迅速导入大量新数据。
- 恢复所有备份数据。
TiDB Lightning 整体架构
配置tidb-lightning.toml
1 | vi tidb-lightning.toml |
1 | [lightning] |
执行导入命令
1 | ./bin/tidb-lightning -config tidb-lightning.toml |
出现错误不需要理会,等待导入完成
导入完毕后,TiDB Lightning 会自动退出。若导入成功,日志的最后一行会显示
tidb lightning exit
。
检查是否导入成功
登录TiDB检查导入是否成功
1 | mysql -u root -P 4000 -h 192.168.64.152 |
到这里基本上已经确定导入成功