我的书签
添加书签
移除书签TiDB Data Migration 表路由
使用 TiDB Data Migration (DM) 迁移数据时，你可以配置表路由 (Table Routing) 规则，指定将上游 MySQL/MariaDB 实例的特定表迁移到下游的特定表。
注意
- 不支持对同一个表设置多个不同的路由规则。
- Schema 的匹配规则需要单独设置，用来迁移
CREATE/DROP SCHEMA ...，例如下面配置表路由中的 rule-2。
配置表路由
在迁移任务配置文件中，添加如下配置：
1. routes:
2. rule-1:
3. schema-pattern: "test_*"
4. table-pattern: "t_*"
5. target-schema: "test"
6. target-table: "t"
7. # extract-table、extract-schema 和 extract-source 为可选配置，仅在需要提取分表、分库和数据源信息时填写
8. extract-table:
9. table-regexp: "t_(.*)"
10. target-column: "c_table"
11. extract-schema:
12. schema-regexp: "test_(.*)"
13. target-column: "c_schema"
14. extract-source:
15. source-regexp: "(.*)"
16. target-column: "c_source"
17. rule-2:
18. schema-pattern: "test_*"
19. target-schema: "test"
在简单任务场景下，推荐使用通配符匹配库表名，但需注意以下版本差异：
- 对于 v1.0.5 版及后续版本，表路由支持通配符匹配。但注意所有版本中通配符匹配中的
*符号 只能有一个，且必须在末尾。 - 对于 v1.0.5 以前的版本，表路由支持通配符，但不支持
[...]与[!...]表达式。
参数解释
- 对于匹配上 schema-pattern/table-pattern 规则的上游 MySQL/MariaDB 实例的表，DM 将它们迁移到下游的
target-schema/target-table。 - 对于匹配上
schema-pattern/table-pattern规则的分表，DM 通过extract-table.table-regexp提取分表信息，通过extract-schema.schema-regexp提取分库信息，通过extract-source.source-regexp提取数据来源信息，然后写入到下游合表对应的target-column中。
使用示例
下面展示了四个不同场景下的配置示例。如果你需要从小数据量分库分表 MySQL 合并迁移数据到 TiDB，请参考这篇文档
分库分表合并
假设存在分库分表场景，需要将上游两个 MySQL 实例的表 test_{1,2,3...}.t_{1,2,3...} 迁移到下游 TiDB 的一张表 test.t。
为了迁移到下游实例的表 test.t，需要创建以下表路由规则：
rule-1用来迁移匹配上schema-pattern: "test_*"和table-pattern: "t_*"的表的 DML/DDL 语句到下游的test.t。rule-2用来迁移匹配上schema-pattern: "test_*"的库的 DDL 语句，例如CREATE/DROP SCHEMA xx。
注意
- 如果下游 TiDB
schema: test已经存在，并且不会被删除，则可以省略rule-2。 - 如果下游 TiDB
schema: test不存在，只设置了rule_1，则迁移会报错schema test doesn't exist。
1. rule-1:
2. schema-pattern: "test_*"
3. table-pattern: "t_*"
4. target-schema: "test"
5. target-table: "t"
6. rule-2:
7. schema-pattern: "test_*"
8. target-schema: "test"
提取分库分表数据源信息写入合表
假设存在分库分表场景，需要将上游两个 MySQL 实例的表 test_{11,12,13...}.t_{1,2,3...} 迁移到下游 TiDB 的一张表 test.t，同时需要提取分库分表的源信息写入下游合表中，用于标识合表中各行数据的来源。
为了迁移到下游实例的表 test.t，需要创建和分库分表合并场景类似的表路由规则，并在其中增加 extract-table、extract-schema、extract-source 配置用于提取分库分表源数据信息：
extract-table：对于匹配上schema-pattern和table-pattern的分表，DM 根据table-regexp提取分表，并将去除t_后的后缀信息写入合表的target-column，即c_table列中。extract-schema：对于匹配上schema-pattern和table-pattern的分库，DM 根据schema-regexp提取分库，并将去除test_后的后缀信息写入合表的target-column，即c_schema列中。extract-source：对于匹配上schema-pattern和table-pattern的分表，DM 将其数据源信息写入合表的target-column，即c_source列中。
1. rule-1:
2. schema-pattern: "test_*"
3. table-pattern: "t_*"
4. target-schema: "test"
5. target-table: "t"
6. extract-table:
7. table-regexp: "t_(.*)"
8. target-column: "c_table"
9. extract-schema:
10. schema-regexp: "test_(.*)"
11. target-column: "c_schema"
12. extract-source:
13. source-regexp: "(.*)"
14. target-column: "c_source"
15. rule-2:
16. schema-pattern: "test_*"
17. target-schema: "test"
为了提取上游分表来源信息数据以写入到下游合表，必须在启动迁移任务前手动在下游创建好对应合表，合表需要包含用于存放分表源数据信息的三个扩展列 target-column （表名列、库名列、数据源列），扩展列必须为表末尾列且必须为字符串类型。
1. CREATE TABLE `test`.`t` (
2. a int(11) PRIMARY KEY,
3. c_table varchar(10) DEFAULT NULL,
4. c_schema varchar(10) DEFAULT NULL,
5. c_source varchar(10) DEFAULT NULL
6. );
例如，上游源数据为：
数据源 mysql-01:
1. mysql> select * from test_11.t_1;
2. +---+
3. | a |
4. +---+
5. | 1 |
6. +---+
7. mysql> select * from test_11.t_2;
8. +---+
9. | a |
10. +---+
11. | 2 |
12. +---+
13. mysql> select * from test_12.t_1;
14. +---+
15. | a |
16. +---+
17. | 3 |
18. +---+
数据源 mysql-02:
1. mysql> select * from test_13.t_3;
2. +---+
3. | a |
4. +---+
5. | 4 |
6. +---+
则 DM 同步后合表中的数据将为：
1. mysql> select * from test.t;
2. +---+---------+----------+----------+
3. | a | c_table | c_schema | c_source |
4. +---+---------+----------+----------+
5. | 1 | 1 | 11 | mysql-01 |
6. | 2 | 2 | 11 | mysql-01 |
7. | 3 | 1 | 12 | mysql-01 |
8. | 4 | 3 | 13 | mysql-02 |
9. +---+---------+----------+----------+
错误的合表建表示例：
注意
以下错误都可能导致分库分表数据源信息写入合表失败。
c-table列不在末尾
1. CREATE TABLE `test`.`t` (
2. c_table varchar(10) DEFAULT NULL,
3. a int(11) PRIMARY KEY,
4. c_schema varchar(10) DEFAULT NULL,
5. c_source varchar(10) DEFAULT NULL
6. );
c-source列缺失
1. CREATE TABLE `test`.`t` (
2. a int(11) PRIMARY KEY,
3. c_table varchar(10) DEFAULT NULL,
4. c_schema varchar(10) DEFAULT NULL,
5. );
c_schema列为非 string 类型
1. CREATE TABLE `test`.`t` (
2. a int(11) PRIMARY KEY,
3. c_table varchar(10) DEFAULT NULL,
4. c_schema int(11) DEFAULT NULL,
5. c_source varchar(10) DEFAULT NULL,
6. );
分库合并
假设存在分库场景，将上游两个 MySQL 实例 test_{1,2,3...}.t_{1,2,3...} 迁移到下游 TiDB 的 test.t_{1,2,3...}，创建一条路由规则即可：
1. rule-1:
2. schema-pattern: "test_*"
3. target-schema: "test"
错误的表路由
假设存在下面两个路由规则，test_1_bak.t_1_bak 可以匹配上 rule-1 和 rule-2，违反 table 路由的限制而报错。
1. rule-0:
2. schema-pattern: "test_*"
3. target-schema: "test"
4. rule-1:
5. schema-pattern: "test_*"
6. table-pattern: "t_*"
7. target-schema: "test"
8. target-table: "t"
9. rule-2:
10. schema-pattern: "test_1_bak"
11. table-pattern: "t_1_bak"
12. target-schema: "test"
13. target-table: "t_bak"
