从兼容 MySQL 的数据库迁移数据——以 Amazon Aurora MySQL 为例

本文以 Amazon Aurora MySQL 为例介绍如何使用 DM 从 MySQL 兼容的数据库迁移数据到 TiDB。

示例使用的 Aurora 集群信息如下：

Aurora 集群数据与迁移计划如下：

迁移使用的 Aurora 集群用户如下：

示例使用的 TiDB 集群信息如下。该集群使用 TiDB Cloud 服务一键部署：

迁移使用的 TiDB 集群用户如下：

预期迁移后，TiDB 集群中存在表`migrate_me`.`t1`与`migrate_me`.`t2`，其中数据与 Aurora 集群一致。

第 1 步：数据迁移前置条件

为了保证迁移成功，在开始迁移之前需要进行前置条件的检查。本文在此列出了需要的检查以及与 DM、Aurora 组件相关的解决方案。

DM 部署节点

DM 作为数据迁移的核心，需要正常连接上游 Aurora 集群与下游 TiDB 集群，因此通过 MySQL client 等方式检查部署 DM 的节点是否能连通上下游。除此以外，关于 DM 节点数目、软硬件等要求，参见 DM 集群软硬件环境需求。

Aurora

DM 在增量复制阶段依赖 ROW 格式的 binlog，参见为 Aurora 实例启用 binlog 进行配置。

如果 Aurora 已开启了 GTID，则可以基于 GTID 进行数据迁移。GTID 的启用方式参见为 Aurora 集群启用 GTID 支持。基于 GTID 进行数据迁移，需要将第 3 步数据源配置文件中的 enable-gtid 设置为 true。

第 2 步：部署 DM 集群

DM 可以通过多种方式进行部署，目前推荐使用 TiUP 部署 DM 集群。具体部署方法，参见使用 TiUP 部署 DM 集群。示例有两个数据源，因此需要至少部署两个 DM-worker 节点。

部署完成后，需要记录任意一台 DM-master 节点的 IP 和服务端口（默认为 8261），以供 dmctl 连接。本示例使用 127.0.0.1:8261。通过 TiUP 使用 dmctl 检查 DM 状态：

tiup dmctl --master-addr 127.0.0.1:8261 list-member

返回值中的 master 与 worker 与部署数目一致：

{
    "result": true,
    "msg": "",
    "members": [
        {
            "leader": {
                ...
            }
        },
        {
            "master": {
                "msg": "",
                "masters": [
                    ...
                ]
            }
        },
        {
            "worker": {
                "msg": "",
                "workers": [
                    ...
                ]
            }
        }
    ]
}

第 3 步：配置数据源

根据示例信息保存如下的数据源配置文件，其中 source-id 的值将在第 4 步配置任务时被引用。

文件 source1.yaml：

# Aurora-1
source-id: "aurora-replica-01"

# 基于 GTID 进行数据迁移时，需要将该项设置为 true
enable-gtid: false

from:
  host: "test-dm-2-0.cluster-czrtqco96yc6.us-east-2.rds.amazonaws.com"
  user: "root"
  password: "12345678"
  port: 3306

文件 source2.yaml：

# Aurora-2
source-id: "aurora-replica-02"

enable-gtid: false

from:
  host: "test-dm-2-0-2.cluster-czrtqco96yc6.us-east-2.rds.amazonaws.com"
  user: "root"
  password: "12345678"
  port: 3306

参见使用 DM 迁移数据：创建数据源，通过 TiUP 使用 dmctl 添加两个数据源。

tiup dmctl --master-addr 127.0.0.1:8261 operate-source create dm-test/source1.yaml
tiup dmctl --master-addr 127.0.0.1:8261 operate-source create dm-test/source2.yaml

添加数据源成功时，每个数据源的返回信息中包含了一个与之绑定的 DM-worker。

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "aurora-replica-01",
            "worker": "one-dm-worker-ID"
        }
    ]
}

第 4 步：配置任务

本示例选择迁移 Aurora 已有数据并将新增数据实时迁移给 TiDB，即全量+增量模式。根据上文的 TiDB 集群信息、已添加的 source-id、要迁移的表，保存如下任务配置文件 task.yaml：

# 任务名，多个同时运行的任务不能重名
name: "test"
# 全量+增量 (all) 迁移模式
task-mode: "all"
# 下游 TiDB 配置信息
target-database:
  host: "tidb.6657c286.23110bc6.us-east-1.prod.aws.tidbcloud.com"
  port: 4000
  user: "root"
  password: "87654321"

# 当前数据迁移任务需要的全部上游 MySQL 实例配置
mysql-instances:
- source-id: "aurora-replica-01"
  # 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置
  block-allow-list: "global"
  mydumper-config-name: "global"

- source-id: "aurora-replica-02"
  block-allow-list: "global"
  mydumper-config-name: "global"

# 黑白名单配置
block-allow-list:
  global:                             # 被上文 block-allow-list: "global" 引用
    do-dbs: ["migrate_me"]            # 需要迁移的上游数据库白名单。白名单以外的库表不会被迁移

# Dump 单元配置
mydumpers:
  global:                             # 被上文 mydumper-config-name: "global" 引用
    extra-args: "--consistency none"  # Aurora 不支持 FTWRL，配置此项以绕过

第 5 步：启动任务

通过 TiUP 使用 dmctl 启动任务。

tiup dmctl --master-addr 127.0.0.1:8261 start-task /absolute/path/to/task.yaml --remove-meta

启动成功时的返回信息是：

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "aurora-replica-01",
            "worker": "one-dm-worker-ID"
        },
        {
            "result": true,
            "msg": "",
            "source": "aurora-replica-02",
            "worker": "another-dm-worker-ID"
        }
    ]
}

如果返回信息中有 source db replication privilege checker、source db dump privilege checker 错误，请检查 errorMsg 字段是否存在不能识别的权限。例如：

line 1 column 287 near \"INVOKE LAMBDA ON *.* TO...

以上返回信息说明 INVOKE LAMBDA 权限导致报错。如果该权限是 Aurora 特有的，请在配置文件中添加如下内容跳过检查。DM 会在版本更新中增强对 Aurora 权限的自动处理。

ignore-checking-items: ["replication_privilege","dump_privilege"]

第 6 步：查询任务并验证数据

通过 TiUP 使用 dmctl 查询正在运行的迁移任务及任务状态等信息。

tiup dmctl --master-addr 127.0.0.1:8261 query-status

任务正常运行的返回信息是：

{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "test",
            "taskStatus": "Running",
            "sources": [
                "aurora-replica-01",
                "aurora-replica-02"
            ]
        }
    ]
}

用户也可以在下游查询数据，在 Aurora 中修改数据并验证到 TiDB 的数据复制。