如何配置下游库列比上游多的场景

🪐 TiDB 技术问题 备份&数据迁移
1

我们需要将上游200多库（库里表是相同的）合并迁移。所以需要在每个表里增加字段，用来区分是哪个库的。

所以下游库的所有表，就比上游多出一个字段。

现在只能通过命令，而且只能是任务中止时，才能使用，同时还必需针对每一个源库运行一个命令。

是否通过配置的方法，忽略列不匹配问题？

2

官网搜索不到吗，我这可以搜索到的呢

image
image2632×1476 302 KB

3

这个能搜索到啊。
但必需每个数据库用命令配置一次，
我这边的数据库分成了上百个。。。

4

https://docs.pingcap.com/zh/tidb-data-migration/stable/precheck#关闭检查项

关闭表结构的检查看看，注意下游比上游多列的情况，有一些限制

image
image1604×680 93.4 KB

5

我关闭了
schema_of_shard_tables 关闭检查上游 MySQL 多实例分库分表的表结构一致性

还是提示：
ErrCode": 36027,
“ErrClass”: “sync-unit”,
“ErrScope”: “internal”,
“ErrLevel”: “high”,
“Message”: “startLocation: [position: (, 0), gtid-set: ], endLocation: [position: (mysql-bin.000001, 29330687), gtid-set: ]: gen update sqls failed, schema: easy_manage, table: smart_app_customer: Column count doesn’t match value count: 52 (columns) vs 51 (values)”,
“RawCause”: “”,
“Workaround”: “”

6

我换了一种方案，在上游增加列，以达到和下游数据库列一样的情况。
但
可以全量迁移，但无法实时同步了。

----------- 全局配置 -----------

********* 基本信息配置 *********

name: testdm # 任务名称，需要全局唯一
shard-mode: “pessimistic” # 如果为分库分表合并任务则需要配置该项。默认使用悲观协调模式 “pessimistic”，在深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 “optimistic”
task-mode: all # 任务模式，可设为 “full” - “只进行全量数据迁移”、“incremental” - “Binlog 实时同步”、“all” - “全量 + Binlog 迁移”
meta-schema: “dm_meta” # 下游储存 meta 信息的数据库
ignore-checking-items: [“all”] #不检查自增ID,关闭检查上游 MySQL 多实例分库分表的表结构一致性

target-database: # 下游数据库实例配置
host: “**********”
port: 4000
user: “root”
password: “”

******** 功能配置集 **********

routes: # 上游和下游表之间的路由 table routing 规则集
rule-customer: # 配置名称
schema-pattern: “" # 库名匹配规则，支持通配符 "” 和 “?”
#table-pattern: “smart_app_customer” # 表名匹配规则，支持通配符 “*” 和 “?”
target-schema: “easy_manage” # 目标库名称
#target-table: “smart_app_customer” # 目标表名称

block-allow-list: # 定义数据源迁移表的过滤规则，可以定义多个规则。
hospital-rule: # 规则名称
do-dbs: [“guard_easy240”,“guard_easy239”] # 迁移哪些库
do-tables: # 迁移哪些表
- db-name: “*”
tbl-name: “smart_app_customer”

----------- 实例配置 -----------

mysql-instances:

source-id: "aliyun"                      # 从 source-id = aliyun 的数据源迁移数据
route-rules: ["rule-customer"]           # 该上游数据库实例匹配的表到下游数据库的 table routing 规则名称
block-allow-list:  "hospital-rule"       # 该上游数据库实例匹配的表的 block-allow-list 过滤规则名称
7

上游数据结构

CREATE TABLE smart_app_customer (
snowId bigint(20) DEFAULT NULL,
customerId bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘客户编号’,
<略>
) ENGINE=InnoDB AUTO_INCREMENT=1411 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC COMMENT=‘顾客’;

下游数据库结构

CREATE TABLE smart_app_customer (
snowId bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键id 唯一标识’,
customerId bigint(20) DEFAULT NULL COMMENT ‘客户编号’,
<略>
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci AUTO_INCREMENT=94615 COMMENT=‘顾客’;

8

这个我确认了下，目前下游比上游多列的支持，需要是在 task 已经跑起来后，下游再额外加上的。

如果一开始上下游不一致的话，需要一些人为操作即官网的操作 https://docs.pingcap.com/zh/tidb-data-migration/stable/usage-scenario-downstream-more-columns

9

这样就是说大概200多个库，每个库200多个表，要先暂停掉任务，然后运行对应每个表不同的，4万多条的命令了。

10

能在上游增加下游对应的字段，设置为空值

而在下游设置为自增，这样需要怎么配置呢？

11

使用这个方案处理。后续的同步也只成功了一次。第二次后的编辑操作就没有成功同步过来。
上传中：dm-master.log… dm-worker.log (81.8 KB) dm-master.7z (138.7 KB)

12

回归到这个帖子的首贴，你这边是想做 下游数据库比上游数据库多列的情况

这块建议你先不做变更，将上游数据全量导入到下游数据库中，等到 sync 阶段，在下游添加列，不需要对同步任务进行额外的操作。

如果一开始上下游不一致的话，需要一些人为操作即官网的操作，针对你的场景这块不推荐，操作量过大。 https://docs.pingcap.com/zh/tidb-data-migration/stable/usage-scenario-downstream-more-columns

13

另外上下游列的数量不一致，设置 shard-mode 为 optimistic 模式