从小数据量分库分表 MySQL 合并迁移数据到 TiDB
- TiB 级以内的分库分表数据合并迁移
- 基于 MySQL binlog 的增量、持续分库分表合并迁移
若要迁移分表总和 1 TiB 以上的数据,则 DM 工具耗时较长,可参考从大数据量分库分表 MySQL 合并迁移数据到 TiDB。
本文以一个简单的场景为例,示例中的两个数据源 MySQL 实例的分库和分表数据迁移至下游 TiDB 集群。示意图如下。
数据源 MySQL 实例 1 和 实例 2 均使用以下表结构,计划将 store_01 和 store_02 中 sale 开头的表合并导入下游 store.sale 表
迁移目标库的结构如下:
分表数据冲突检查
迁移中如果涉及合库合表,来自多张分表的数据可能引发主键或唯一索引的数据冲突。因此在迁移之前,需要检查各分表数据的业务特点。详情请参考跨分表数据在主键或唯一索引冲突处理
在本示例中: 和 sale_02
具有相同的表结构如下:
其中id
列为主键,sid
列为分片键,具有全局唯一性。id
列具有自增属性,多个分表范围重复会引发数据冲突。sid
可以保证全局满足唯一索引,因此可以按照参考中介绍的操作绕过id
列。在下游创建sale
表时移除id
列的唯一键属性
CREATE TABLE `sale` (
`id` bigint(20) NOT NULL,
`pid` bigint(20) NOT NULL,
`comment` varchar(255) DEFAULT NULL,
INDEX (`id`),
UNIQUE KEY `sid` (`sid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
在终端中执行下面的命令,使用tiup dmctl
将数据源配置加载到 DM 集群中:
tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml
该命令中的参数描述如下:
重复以上操作直至所有数据源均添加完成。
第 2 步: 创建迁移任务
新建task1.yaml
文件, 写入以下内容:
以上内容为执行迁移的最小任务配置。关于任务的更多配置项,可以参考DM 任务完整配置文件介绍
若想了解配置文件中routes
,等更多用法,请参考:
在你启动数据迁移任务之前,建议使用check-task
命令检查配置是否符合 DM 的配置要求,以降低后期报错的概率。
tiup dmctl --master-addr ${advertise-addr} check-task task.yaml
使用 tiup dmctl
执行以下命令启动数据迁移任务。
如果任务启动失败,可根据返回结果的提示进行配置变更后执行 start-task task.yaml 命令重新启动任务。遇到问题请参考 以及 常见问题
第 4 步: 查看任务状态
如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息,可使用tiup dmctl
执行query-status
命令进行查询:
tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}
关于查询结果的详细解读,请参考查询状态
你可以通过 Grafana 或者日志查看迁移任务的历史状态以及各种内部运行指标。
通过 Grafana 查看
如果使用 TiUP 部署 DM 集群时,正确部署了 Prometheus、Alertmanager 与 Grafana,则使用部署时填写的 IP 及 端口进入 Grafana,选择 DM 的 dashboard 查看 DM 相关监控项。
通过日志查看
DM 在运行过程中,DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息,其中包含迁移任务的相关信息。各组件的日志目录如下:
- DM-master 日志目录:通过 DM-master 进程参数
--log-file
设置。如果使用 TiUP 部署 DM,则日志目录默认位于/dm-deploy/dm-master-8261/log/
。 - DM-worker 日志目录:通过 DM-worker 进程参数
--log-file
设置。如果使用 TiUP 部署 DM,则日志目录默认位于/dm-deploy/dm-worker-8262/log/
。
- DM-master 日志目录:通过 DM-master 进程参数