从 Amazon Aurora 迁移数据到 TiDB

    • 使用 Lightning 导入全量数据到 TiDB
    • 使用 DM 持续增量同步到 TiDB（可选）

    1. 在 Aurora 上，执行以下命令，查询并记录当前 binlog 位置：

      你将得到类似以下的输出，请记录 binlog 名称和位置，供后续步骤使用：

      2.  | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
      3.  +------------------+----------+--------------+------------------+-------------------+
      4.  | mysql-bin.000002 |    52806 |              |                  |                   |
      5.  +------------------+----------+--------------+------------------+-------------------+
      6.  1 row in set (0.012 sec)

    2. 导出 Aurora 快照文件。具体方式请参考 Aurora 的官方文档：Exporting DB snapshot data to Amazon S3.

    请注意，上述两步的时间间隔建议不要超过 5 分钟，否则记录的 binlog 位置过旧可能导致增量同步时产生数据冲突。

    完成上述两步后，你需要准备好以下信息：

    • 创建快照点时，Aurora binlog 的名称及位置。
    • 快照文件的 S3 路径，以及具有访问权限的 SecretKey 和 AccessKey。

    第 2 步： 导出 schema

    因为 Aurora 生成的快照文件并不包含建表语句文件，所以你需要使用 Dumpling 自行导出 schema 并使用 Lightning 在下游创建 schema。你也可以跳过此步骤，并以手动方式在下游自行创建 schema。

    运行以下命令，建议使用 --filter 参数仅导出所需表的 schema：

    1. tiup dumpling --host ${host} --port 3306 --user root --password ${password} --filter 'my_db1.table[12]' --no-data --output 's3://my-bucket/schema-backup?region=us-west-2' --filter "mydb.*"

    命令中所用参数描述如下。如需更多信息可参考 Dumpling overview。

    第 3 步： 编写 Lightning 配置文件

    根据以下内容创建tidb-lightning.toml 配置文件：

    1. vim tidb-lightning.toml

    如果需要在 TiDB 开启 TLS ，请参考 TiDB Lightning Configuration。

      1.  tiup tidb-lightning -config tidb-lightning.toml -d 's3://my-bucket/schema-backup?region=us-west-2'

    2. 导入开始后，可以采用以下任意方式查看进度：

      • 通过 grep 日志关键字 progress 查看进度，默认 5 分钟更新一次。
      • 通过监控面板查看进度，请参考 TiDB Lightning 监控。
      • 通过 Web 页面查看进度，请参考 。

    3. 导入完毕后，TiDB Lightning 会自动退出。查看日志的最后 5 行中会有 the whole procedure completed，则表示导入成功。

    如果导入过程中遇到问题，请参见 TiDB Lightning 常见问题。

    前提条件

    第 1 步： 创建数据源

    1. 新建source1.yaml文件, 写入以下内容：

      1.  # 唯一命名，不可重复。
      2.  source-id: "mysql-01"
      4.  # DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是上游 MySQL 已开启 GTID 模式。若上游存在主从自动切换，则必须使用 GTID 模式。
      5.  enable-gtid: false
      7.  from:
      8.    host: "${host}"         # 例如：172.16.10.81
      9.    user: "root"
      10.    password: "${password}" # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用
      11.    port: 3306

    2. 在终端中执行下面的命令，使用 tiup dmctl 将数据源配置加载到 DM 集群中:

      该命令中的参数描述如下：

    新建 task1.yaml 文件, 写入以下内容：

    1. # 任务名，多个同时运行的任务不能重名。
    2. name: "test"
    3. # 任务模式，可设为
    4. # full：只进行全量数据迁移
    5. # incremental： binlog 实时同步
    6. # all： 全量 + binlog 迁移
    7. task-mode: "incremental"
    8. # 下游 TiDB 配置信息。
    9. target-database:
    10.   host: "${host}"                   # 例如：172.16.10.83
    11.   user: "root"
    12.   password: "${password}"           # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用
    14. # 黑白名单全局配置，各实例通过配置项名引用。
    15. block-allow-list:                     # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
    16.   listA:                              # 名称
    17.     do-tables:                        # 需要迁移的上游表的白名单。
    18.     - db-name: "test_db"              # 需要迁移的表的库名。
    21. # 配置数据源
    22. mysql-instances:
    23.   - source-id: "mysql-01"               # 数据源 ID，即 source1.yaml 中的 source-id
    24.     block-allow-list: "listA"           # 引入上面黑白名单配置。
    25. #       syncer-config-name: "global"    # 引用上面的 syncers 增量数据配置。
    26.     meta:                               # task-mode 为 incremental 且下游数据库的 checkpoint 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 checkpoint 为准。
    27.       binlog-name: "mysql-bin.000004"   # “Step 1. 导出 Aurora 快照文件到 Amazon S3” 中记录的日志位置，当上游存在主从切换时，必须使用 gtid。
    28.       binlog-pos: 109227
    29.       # binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"
    31.    # 【可选配置】 如果增量数据迁移需要重复迁移已经在全量数据迁移中完成迁移的数据，则需要开启 safe mode 避免增量数据迁移报错。
    32.    ##  该场景多见于以下情况：全量迁移的数据不属于数据源的一个一致性快照，随后从一个早于全量迁移数据之前的位置开始同步增量数据。
    33.    # syncers:            # sync 处理单元的运行配置参数。
    34.    #  global:           # 配置名称。
    35.    #    safe-mode: true # 设置为 true，会将来自数据源的 INSERT 改写为 REPLACE，将 UPDATE 改写为 DELETE 与 REPLACE，从而保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 1 分钟内 TiDB DM 会自动启动 safe mode。

    以上内容为执行迁移的最小任务配置。关于任务的更多配置项，可以参考

    第 3 步： 启动任务

    在你启动数据迁移任务之前，建议使用 check-task 命令检查配置是否符合 DM 的配置要求，以降低后期报错的概率：

    1. tiup dmctl --master-addr ${advertise-addr} check-task task.yaml

    使用 tiup dmctl 执行以下命令启动数据迁移任务。

    1. tiup dmctl --master-addr ${advertise-addr} start-task task.yaml

    该命令中的参数描述如下：

    参数 描述
    --master-addr dmctl 要连接的集群的任意 DM-master 节点的 {advertise-addr}，例如： 172.16.10.71:8261
    start-task 命令用于创建数据迁移任务

    如果任务启动失败，可根据返回结果的提示进行配置变更后，再次执行上述命令，重新启动任务。遇到问题请参考以及常见问题。

    第 4 步： 查看任务状态

    如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息，可使用 tiup dmctl 执行 query-status 命令进行查询：

    关于查询结果的详细解读，请参考查询状态。

    要查看迁移任务的历史状态以及更多的内部运行指标，可参考以下步骤。

    如果使用 TiUP 部署 DM 集群时，正确部署了 Prometheus、Alertmanager 与 Grafana，则使用部署时填写的 IP 及端口进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。

    • DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录默认位于 /dm-deploy/dm-master-8261/log/。
    • DM-worker 日志目录：通过 DM-worker 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录默认位于 /dm-deploy/dm-worker-8262/log/。