| title | category |
|---|---|
Data Migration 简介 |
tools |
DM (Data Migration) 是一体化的数据同步任务管理平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步。使用 DM 工具有利于简化错误处理流程，降低运维成本。
DM 主要包括三个组件：DM-master，DM-worker 和 dmctl。
DM-master 负责管理和调度数据同步任务的各项操作。
- 保存 DM 集群的拓扑信息
- 监控 DM-worker 进程的运行状态
- 监控数据同步任务的运行状态
- 提供数据同步任务管理的统一入口
- 协调分库分表场景下各个实例分表的 DDL 同步
DM-worker 负责执行具体的数据同步任务。
- 将 binlog 数据持久化保存在本地
- 保存数据同步子任务的配置信息
- 编排数据同步子任务的运行
- 监控数据同步子任务的运行状态
DM-worker 启动后，会自动同步上游 binlog 至本地配置目录（如果使用 DM-Ansible 部署 DM 集群，默认的同步目录为 <deploy_dir>/relay_log）。关于 DM-worker，详见 DM-worker 简介。关于 relay log，详见 DM Relay Log。
dmctl 是用来控制 DM 集群的命令行工具。
- 创建、更新或删除数据同步任务
- 查看数据同步任务状态
- 处理数据同步任务错误
- 校验数据同步任务配置的正确性
下面简单介绍 DM 数据同步功能的核心特性。
Table routing 是指将上游 MySQL 或 MariaDB 实例的某些表同步到下游指定表的路由功能，可以用于分库分表的合并同步。
Black & white table lists 是指上游数据库实例表的黑白名单过滤规则。其过滤规则类似于 MySQL replication-rules-db/replication-rules-table，可以用来过滤或只同步某些数据库或某些表的所有操作。
Binlog event filter 是比库表同步黑白名单更加细粒度的过滤规则，可以指定只同步或者过滤掉某些 schema/table 的指定类型的 binlog events，比如 INSERT，TRUNCATE TABLE。
Column mapping 是指根据用户指定的内置表达式对表的列进行转换，可以用来解决分库分表合并时自增主键 ID 的冲突。
DM 支持对原分库分表进行合库合表操作，但需要满足一些使用限制。
在使用 DM 工具之前，需了解以下限制：
-
数据库版本
- 5.5 < MySQL 版本 < 5.8
- MariaDB 版本 >= 10.1.2
在使用 dmctl 启动任务时，DM 会自动对任务上下游数据库的配置、权限等进行前置检查。
-
DDL 语法
-
目前，TiDB 部分兼容 MySQL 支持的 DDL 语句。因为 DM 使用 TiDB parser 来解析处理 DDL 语句，所以目前仅支持 TiDB parser 支持的 DDL 语法。详见 TiDB DDL 语法支持。
-
DM 遇到不兼容的 DDL 语句时会报错。要解决此报错，需要使用 dmctl 手动处理，要么跳过该 DDL 语句，要么用指定的 DDL 语句来替换它。
-
-
分库分表
- 如果业务分库分表之间存在数据冲突，冲突的列只有自增主键列，并且列的类型是 bigint，可以尝试使用 Column mapping 来解决；否则不推荐使用 DM 进行同步，如果进行同步则有冲突的数据会相互覆盖造成数据丢失。
- 关于分库分表合并场景的其它限制，参见使用限制。
-
操作限制
- DM-worker 重启后不能自动恢复数据同步任务，需要使用 dmctl 手动执行
start-task。详见管理数据同步任务。 - 在一些情况下，DM-worker 重启后不能自动恢复 DDL lock 同步，需要手动处理。详见手动处理 Sharding DDL Lock。
- DM-worker 重启后不能自动恢复数据同步任务，需要使用 dmctl 手动执行