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

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

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

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

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

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

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

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

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

    Aurora

    DM 在增量复制阶段依赖 ROW 格式的 binlog，参见 进行配置。

    注意：

    • 基于 GTID 进行数据迁移需要 MySQL 5.7 (Aurora 2.04) 或更高版本。
    • 除上述 Aurora 特有配置以外，上游数据库需满足迁移 MySQL 的其他要求，例如表结构、字符集、权限等，参见上游 MySQL 实例检查内容。

    第 2 步：部署 DM 集群

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

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

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

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "members": [
    5.         {
    6.             "leader": {
    7.                 ...
    8.             }
    9.         },
    10.         {
    11.             "master": {
    12.                 "msg": "",
    13.                 "masters": [
    14.                     ...
    15.                 ]
    16.             }
    17.         },
    18.         {
    19.             "worker": {
    20.                 "msg": "",
    21.                 "workers": [
    22.                     ...
    23.                 ]
    24.             }
    25.     ]
    26. }

    注意：

    DM 所使用的配置文件支持明文或密文数据库密码，推荐使用密文数据库密码确保安全。如何获得密文数据库密码，参见。

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

    文件 ：

    1. # Aurora-1
    2. source-id: "aurora-replica-01"
    4. # 基于 GTID 进行数据迁移时，需要将该项设置为 true
    5. enable-gtid: false
    7. from:
    8.   host: "test-dm-2-0.cluster-czrtqco96yc6.us-east-2.rds.amazonaws.com"
    9.   user: "root"
    10.   password: "12345678"
    11.   port: 3306

    文件 source2.yaml：

    1. # Aurora-2
    2. source-id: "aurora-replica-02"
    4. enable-gtid: false
    6. from:
    7.   host: "test-dm-2-0-2.cluster-czrtqco96yc6.us-east-2.rds.amazonaws.com"
    8.   user: "root"
    9.   password: "12345678"
    10.   port: 3306

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

    1. {
    2.     "result": true,
    3.     "msg": "",
    4.     "sources": [
    5.         {
    6.             "result": true,
    7.             "msg": "",
    8.             "source": "aurora-replica-01",
    9.             "worker": "one-dm-worker-ID"
    10.         }
    11.     ]

    第 4 步：配置任务

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

    1. # 任务名，多个同时运行的任务不能重名
    3. # 全量+增量 (all) 迁移模式
    4. task-mode: "all"
    5. # 下游 TiDB 配置信息
    6. target-database:
    7.   host: "tidb.6657c286.23110bc6.us-east-1.prod.aws.tidbcloud.com"
    8.   port: 4000
    9.   user: "root"
    10.   password: "87654321"
    12. # 当前数据迁移任务需要的全部上游 MySQL 实例配置
    13. mysql-instances:
    14. - source-id: "aurora-replica-01"
    15.   # 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置
    16.   block-allow-list: "global"
    17.   mydumper-config-name: "global"
    19. - source-id: "aurora-replica-02"
    20.   block-allow-list: "global"
    21.   mydumper-config-name: "global"
    23. # 黑白名单配置
    24. block-allow-list:
    25.   global:                             # 被上文 block-allow-list: "global" 引用
    26.     do-dbs: ["migrate_me"]            # 需要迁移的上游数据库白名单。白名单以外的库表不会被迁移
    28. # Dump 单元配置
    29. mydumpers:
    30.   global:                             # 被上文 mydumper-config-name: "global" 引用
    31.     extra-args: "--consistency none"  # Aurora 不支持 FTWRL，配置此项以绕过

    通过 TiUP 使用 dmctl 启动任务。

    注意：

    目前通过 TiUP 使用 dmctl 时，需要使用 task.yaml 绝对路径。TiUP 将会在后续更新中正确支持相对路径。

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

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

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

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

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

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

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

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

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