从 MySQL 迁移数据 —— 以 Amazon Aurora MySQL 为例
假设有两个 Aurora 集群需要迁移数据到 TiDB,其集群信息如下,其中 Aurora-1 包含一个独立的读取器节点。
DM 在增量同步阶段依赖 格式的 binlog,如果未启用 binlog 及设置正确的 binlog 格式,则不能正常使用 DM 进行数据同步,具体可参见检查内容。
如果需要基于 GTID 进行数据迁移,还需要为 Aurora 集群启用 GTID 支持。
在 Aurora 集群中,binlog 相关参数是集群参数组中的集群级参数,有关如何为 Aurora 集群启用 binlog 支持,请参考。在使用 DM 进行数据迁移时,需要将 binlog_format
参数设置为 ROW
。
第 2 步:部署 DM 集群
目前推荐使用 DM-Ansible 部署 DM 集群,具体部署方法参照。
使用 DM-Ansible 部署 DM 集群后,相关配置信息如下:
- DM 集群相关组件配置信息
- 上下游数据库实例相关信息
dm-master 进程配置文件
{ansible deploy}/conf/dm-master.toml
中的配置
第 4 步:配置任务
假设需要将 Aurora-1 和 Aurora-2 实例的 test_db
库的 test_table
表以全量+增量的模式同步到下游 TiDB 的 test_db
库的 test_table
表。
复制并编辑 {ansible deploy}/conf/task.yaml.example
,生成如下任务配置文件 task.yaml
:
# 任务名,多个同时运行的任务不能重名。
name: "test"
# 全量+增量 (all) 同步模式。
task-mode: "all"
# 下游 TiDB 配置信息。
target-database:
host: "172.16.10.83"
password: ""
# 当前数据同步任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
# 上游实例或者复制组 ID,参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
source-id: "mysql-replica-01"
# 需要同步的库名或表名的黑白名单的配置项名称,用于引用全局的黑白名单配置,全局配置见下面的 `black-white-list` 的配置。
black-white-list: "global"
# Mydumper 的配置项名称,用于引用全局的 Mydumper 配置。
mydumper-config-name: "global"
-
source-id: "mysql-replica-02"
black-white-list: "global"
mydumper-config-name: "global"
# 黑白名单全局配置,各实例通过配置项名引用。
black-white-list:
global:
- db-name: "test_db" # 需要同步的表的库名。
tbl-name: "test_table" # 需要同步的表的名称。
# Mydumper 全局配置,各实例通过配置项名引用。
mydumpers:
global:
extra-args: "-B test_db -T test_table" # mydumper 的其他参数,从 DM 1.0.2 版本开始,DM 会自动生成 table-list 配置,在其之前的版本仍然需要人工配置。
执行以下命令启动 dmctl
执行以下命令启动数据同步任务(
task.yaml
是之前编辑的配置文件)start-task ./task.yaml
- 如果执行命令后的返回结果中不包含错误信息,则表明任务已经成功启动
如果包含以下错误信息,则表明上游 Aurora 用户可能拥有 TiDB 不支持的权限类型
此时可以选择以下两种处理方法中的任意一种进行处理后,再使用
start-task
尝试重新启动任务:- 为用于进行数据迁移的 Aurora 用户移除不被 TiDB 支持的不必要的权限
如果能确保 Aurora 用户拥有 DM 所需要的权限,可以在
task.yaml
配置文件中添加如下顶级配置项以跳过启用任务时的前置权限检查ignore-checking-items: ["dump_privilege", "replication_privilege"]
第 6 步:查询任务
如需了解 DM 集群中是否存在正在运行的同步任务及任务状态等信息,可在 dmctl 内使用以下命令进行查询: