我们需要将上游200多库(库里表是相同的)合并迁移。所以需要在每个表里增加字段,用来区分是哪个库的。
所以下游库的所有表,就比上游多出一个字段。
现在只能通过命令,而且只能是任务中止时,才能使用,同时还必需针对每一个源库运行一个命令。
是否通过配置的方法,忽略列不匹配问题?
我们需要将上游200多库(库里表是相同的)合并迁移。所以需要在每个表里增加字段,用来区分是哪个库的。
所以下游库的所有表,就比上游多出一个字段。
现在只能通过命令,而且只能是任务中止时,才能使用,同时还必需针对每一个源库运行一个命令。
是否通过配置的方法,忽略列不匹配问题?
这个能搜索到啊。
但必需每个数据库用命令配置一次,
我这边的数据库分成了上百个。。。
我关闭了
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”: “”
我换了一种方案,在上游增加列,以达到和下游数据库列一样的情况。
但
可以全量迁移,但无法实时同步了。
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”
source-id: "aliyun" # 从 source-id = aliyun 的数据源迁移数据
route-rules: ["rule-customer"] # 该上游数据库实例匹配的表到下游数据库的 table routing 规则名称
block-allow-list: "hospital-rule" # 该上游数据库实例匹配的表的 block-allow-list 过滤规则名称
上游数据结构
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=‘顾客’;
这个我确认了下,目前下游比上游多列的支持,需要是在 task 已经跑起来后,下游再额外加上的。
如果一开始上下游不一致的话,需要一些人为操作即官网的操作 https://docs.pingcap.com/zh/tidb-data-migration/stable/usage-scenario-downstream-more-columns
这样就是说大概200多个库,每个库200多个表,要先暂停掉任务,然后运行对应每个表不同的,4万多条的命令了。
能在上游增加下游对应的字段,设置为空值
而在下游设置为自增,这样需要怎么配置呢?
使用这个方案处理。后续的同步也只成功了一次。第二次后的编辑操作就没有成功同步过来。
上传中:dm-master.log… dm-worker.log (81.8 KB) dm-master.7z (138.7 KB)
回归到这个帖子的首贴,你这边是想做 下游数据库比上游数据库多列的情况
这块建议你先不做变更,将上游数据全量导入到下游数据库中,等到 sync 阶段,在下游添加列,不需要对同步任务进行额外的操作。
如果一开始上下游不一致的话,需要一些人为操作即官网的操作,针对你的场景这块不推荐,操作量过大。 https://docs.pingcap.com/zh/tidb-data-migration/stable/usage-scenario-downstream-more-columns
另外上下游列的数量不一致,设置 shard-mode 为 optimistic 模式