课程名称：301 + 3.6.3 Data migration from Aurora（如何将数据从 Aurora 迁移到 TiDB）
学习时长：10min
课程收获：了解分库分表架构下数据库数据如何迁移至 TiDB
课程内容：
DM 架构
Prometheus
Prometheus 用于采集任务监控数据，以便被 Grafana 展示。
dmctl
dmctl 是用来控制 DM 集群的命令行工具。
- 创建、更新或删除数据迁移任务
- 查看数据迁移任务状态
- 处理数据迁移任务错误
- 校验数据迁移任务配置的正确性
DM-master
DM-master 负责管理和调度数据迁移任务的各项操作。
- 保存 DM 集群的拓扑信息
- 监控 DM-worker 进程的运行状态
- 监控数据迁移任务的运行状态
- 提供数据迁移任务管理的统一入口
- 协调分库分表场景下各个实例分表的 DDL 迁移
DM-worker
DM-worker 负责执行具体的数据迁移任务。
- 将 binlog 数据持久化保存在本地
- 保存数据迁移子任务的配置信息
- 编排数据迁移子任务的运行
- 监控数据迁移子任务的运行状态
工作流程
使用限制
在使用 DM 工具之前，需了解以下限制：
- 数据库版本
- 5.5 < MySQL 版本 < 8.0
- MariaDB 版本 >= 10.1.2
注意： 如果上游 MySQL/MariaDB server 间构成主从复制结构，则需要 5.7.1 < MySQL 版本 < 8.0 或者 MariaDB 版本 >= 10.1.3。在使用 dmctl 启动任务时，DM 会自动对任务上下游数据库的配置、权限等进行前置检查。
- DDL 语法
- 目前，TiDB 部分兼容 MySQL 支持的 DDL 语句。因为 DM 使用 TiDB parser 来解析处理 DDL 语句，所以目前仅支持 TiDB parser 支持的 DDL 语法。详见 TiDB DDL 语法支持。
- DM 遇到不兼容的 DDL 语句时会报错。要解决此报错，需要使用 dmctl 手动处理，要么跳过该 DDL 语句，要么用指定的 DDL 语句来替换它。详见如何处理不兼容的 DDL 语句。
- 分库分表
- 操作限制
- DM-worker 重启后不能自动恢复数据迁移任务，需要使用 dmctl 手动执行
start-task。详见管理数据迁移任务。 - 在一些情况下，DM-worker 重启后不能自动恢复 ，需要手动处理。详见手动处理 Sharding DDL Lock。
- DM-worker 重启后不能自动恢复数据迁移任务，需要使用 dmctl 手动执行
- DM-worker 切换 MySQL
- 当 DM-worker 通过虚拟 IP（VIP）连接到 MySQL 且要切换 VIP 指向的 MySQL 实例时，DM 内部不同的 connection 可能会同时连接到切换前后不同的 MySQL 实例，造成 DM 拉取的 binlog 与从上游获取到的其他状态不一致，从而导致难以预期的异常行为甚至数据损坏。如需切换 VIP 指向的 MySQL 实例，请参考虚拟 IP 环境下的上游主从切换对 DM 手动执行变更。
DM 环境准备，详见 使用 DM-Ansible 部署 DM 集群。
DM 集群停启
运行以下命令。如果所有服务都返回 tidb ，则 SSH 互信配置成功。
ansible -i inventory.ini all -m shell -a 'whoami'
运行以下命令。如果所有服务都返回 root ，则 tidb 用户免密 sudo 操作配置成功。
ansible -i inventory.ini all -m shell -a 'whoami' -b
修改内核参数，并部署 DM 集群组件和监控组件。
ansible-playbook deploy.yml
运行以下命令，启动 DM 集群，该操作会按顺序启动 DM 集群的所有组件，包括 DM-master，DM-worker，以及监控组件。当一个 DM 集群被关闭后，您可以使用该命令将其开启：
ansible-playbook start.yml
运行以下命令，关闭DM 集群，该操作会按顺序关闭整个 DM 集群中的所有组件，包括 DM-master，DM-worker，以及监控组件：
ansible-playbook stop.yml
任务配置文件示例
下面是一个基础的配置文件示例，通过该示例可以完成简单的数据迁移功能。
---
# ----------- 全局配置 -----------
## ********* 基本信息配置 *********
name: test # 任务名称，需要全局唯一
task-mode: all # 任务模式，可设为 "full"、"incremental"、"all"
target-database: # 下游数据库实例配置
host: "127.0.0.1"
port: 4000
user: "root"
password: "" # 如果不为空则需经过 dmctl 加密
## ******** 功能配置集 **********
block-allow-list: # 上游数据库实例匹配的表的 block & allow list 过滤规则集，如果 DM 版本 <= v1.0.6 则使用 black-white-list
bw-rule-1: # 黑白名单配置的名称
do-dbs: ["all_mode"] # 迁移哪些库
# ----------- 实例配置 -----------
mysql-instances:
- source-id: "mysql-replica-01" # 上游实例或者复制组 ID，参考 `dm-master.toml` 的 `source-id` 配置
block-allow-list: "bw-rule-1" # 黑白名单配置名称，如果 DM 版本 <= v1.0.6 则使用 black-white-list
mydumper-thread: 4 # dump 处理单元用于导出数据的线程数量，在 v1.0.2 版本引入
loader-thread: 16 # load 处理单元用于导入数据的线程数量，在 v1.0.2 版本引入
syncer-thread: 16 # sync 处理单元用于复制增量数据的线程数量，在 v1.0.2 版本引入
- source-id: "mysql-replica-02" # 上游实例或者复制组 ID，参考 `dm-master.toml` 的 `source-id` 配置
block-allow-list: "bw-rule-1" # 黑白名单配置名称，如果 DM 版本 <= v1.0.6 则使用 black-white-list
mydumper-thread: 4 # dump 处理单元用于导出数据的线程数量，在 v1.0.2 版本引入
loader-thread: 16 # load 处理单元用于导入数据的线程数量，在 v1.0.2 版本引入
syncer-thread: 16 # sync 处理单元用于复制增量数据的线程数量，在 v1.0.2 版本引入
开始执行 DM 任务
进入交互模式，与 DM-master 进行交互：
./dmctl -master-addr 172.16.30.14:8261创建数据迁移任务
start-task命令用于创建数据迁移任务。 当数据迁移任务启动时，DM 将自动对相应权限和配置进行前置检查。start-task [ -w "172.16.30.15:8262"] ./task.yaml查询数据迁移任务状态
query-status