从小数据量分库分表 MySQL 合并迁移数据到 TiDB

    • TiB 级以内的分库分表数据合并迁移
    • 基于 MySQL binlog 的增量、持续分库分表合并迁移

    若要迁移分表总和 1 TiB 以上的数据，则 DM 工具耗时较长，可参考从大数据量分库分表 MySQL 合并迁移数据到 TiDB。

    在本文档的示例中，数据源 MySQL 实例 1 和实例 2 均使用以下表结构，计划将 store_01 和 store_02 中 sale 开头的表合并导入下游 store.sale 表。

    迁移目标库的结构如下：

    分表数据冲突检查

    迁移中如果涉及合库合表，来自多张分表的数据可能引发主键或唯一索引的数据冲突。因此在迁移之前，需要检查各分表数据的业务特点。详情请参考跨分表数据在主键或唯一索引冲突处理。

    在本示例中： 和 sale_02 具有相同的表结构如下：

    其中 id 列为主键，sid 列为分片键，具有全局唯一性。id 列具有自增属性，多个分表范围重复会引发数据冲突。sid 可以保证全局满足唯一索引，因此可以按照参考中介绍的操作绕过 id 列。在下游创建 sale 表时移除 id 列的唯一键属性：

    1. CREATE TABLE `sale` (
    2.   `id` bigint(20) NOT NULL,
    3.   `sid` bigint(20) NOT NULL,
    4.   `pid` bigint(20) NOT NULL,
    6.   INDEX (`id`),
    7.   UNIQUE KEY `sid` (`sid`)
    8. ) ENGINE=InnoDB DEFAULT CHARSET=latin1

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

    1. tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml

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

    重复以上操作直至所有数据源均添加完成。

    第 2 步：创建迁移任务

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

    以上内容为执行迁移的最小任务配置。关于任务的更多配置项，可以参考 DM 任务完整配置文件介绍。

    若想了解配置文件中 routes、filters 等更多用法，请参考：

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

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

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

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

    第 4 步：查看任务状态

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

    1. tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}

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

    你可以通过 Grafana 或者日志查看迁移任务的历史状态以及各种内部运行指标。

    • 通过 Grafana 查看

      如果使用 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/。

    探索更多