DM同步任务在load阶段报错conflict number大于10000

[AC米兰的铁匠]

【 TiDB 使用环境】生产环境
【 TiDB 版本】v8.1.0
【复现路径】重跑任务
【遇到的问题：load阶段报错"ErrCode": 34019】
“RawCause”: “[Lightning:Restore:ErrRestoreTable]restore table gaia_order.t_sale_order_attached failed: The number of conflict errors exceeds the threshold configured by conflict.threshold: ‘10000’”

大家好, 刚开始试用tidb, 在从库跑了个合库的DM任务,遇到这个报错, 搜到了说 TiDB Lightning里max-error默认是10000, 但我目前是DM任务, 不知道这个默认10000在哪里修改
我看了tiup的目录里, 只有dm, dmctl 没有找到Lightning 相关的目录和配置, 大佬们指导下

【资源配置】
【附件：任务状态】
“subTaskStatus”: [
{
“name”: “sop”,
“stage”: “Paused”,
“unit”: “Load”,
“result”: {
“isCanceled”: false,
“errors”: [
{
“ErrCode”: 34019,
“ErrClass”: “load-unit”,
“ErrScope”: “internal”,
“ErrLevel”: “high”,
“Message”: “”,
“RawCause”: “[Lightning:Restore:ErrRestoreTable]restore table xxx_order.t_xxx_attached failed: The number of conflict errors exceeds the threshold configured by conflict.threshold: ‘10000’”,
“Workaround”: “”
}
],
“detail”: null
},
“unresolvedDDLLockID”: “”,
“load”: {
“finishedBytes”: “18199573089”,
“totalBytes”: “40374194074”,
“progress”: “45.08 %”,
“metaBinlog”: “(mybinlog.000742, 980072603)”,
“metaBinlogGTID”: “8ae17138-2fbe-11ec-8167-286ed488e376:1-284293863,eb2e5ab6-2fbf-11ec-92db-0cda411d3c57:1-2”,
“bps”: “82032”
},
“validation”: null
}
]

[AC米兰的铁匠]

loader是调用Lightning进行数据导入的, 但是配置文件引用的是Lightning的默认配置Conflict.MaxRecordRows默认10000, 注释说从8.1开始不需要手动配置这个值…我用了8.1是第一个遇到这个的吗…

[AC米兰的铁匠]

我当前从10个分库地址合库到tidb, 5个已经跑完了处于同步状态, 另5个都报错conflict number到了10000.
这…过不去了

[AC米兰的铁匠]

冲突错误 (Conflict error)

你可以通过修改配置项 conflict.threshold 来增加冲突错误相关的容错数量。如果设置为 N，那么 TiDB Lightning 允许数据源中出现 N 个冲突错误，而且会跳过这些错误继续导入，一旦超过这个错误数就会退出。在逻辑导入模式或者物理导入模式下，不同的场景会产生冲突错误，你可以参考对应导入模式的“冲突检测”文档。该配置项默认值为 9223372036854775807，意味着几乎能容忍全部错误。
7.5的默认值超级大, 怎么到8.1就改成1万了呢, 我降回去跑吧

[Billmay表妹 (表妹)]

我帮你在群里面求助下

[有猫万事足]

感觉是合表的主键/唯一键冲突了吧。

分表和合表的表结构发一下。

感觉调大参数这个方向不可靠，无非是让冲突来的更加猛烈。

[郑旭东石家庄 (Ti D Ber Xh Hfy Sc H)]

与楼上同感，这个情况下不是去找更大的参数设置，而是去分析产生这么多冲突的原因，是否可以调整tidb中表主键或唯一索引的组成。就算是调大了错误数量，同步过去的数据是否可用是一个问题。

[AC米兰的铁匠]

因为有5个库已经加载完了, 数据量都不小. 我想应该不是键冲突, 现在报错都是一个item表, 然后分库是按区域code区分的, 稍等我发一下完整的结构

[AC米兰的铁匠]

5个冲突有三个是这个表, 表结构:
CREATE TABLE t_sale_order_attached (
order_id varchar(64) NOT NULL DEFAULT ‘’ COMMENT ‘订单号’,
region_code varchar(32) DEFAULT NULL COMMENT ‘区域编码’,
region_name varchar(32) DEFAULT NULL COMMENT ‘区域名称’,
receive_latitude varchar(32) DEFAULT ‘’ COMMENT ‘收货维度’,
receive_longitude varchar(32) DEFAULT ‘’ COMMENT ‘收货经度’,
receive_province_id varchar(32) DEFAULT ‘’ COMMENT ‘收货省份编码’,
receive_province_name varchar(64) DEFAULT ‘’ COMMENT ‘收货省份名称’,
receive_city_id varchar(32) DEFAULT ‘’ COMMENT ‘收货城市编码’,
receive_city_name varchar(64) DEFAULT ‘’ COMMENT ‘收货城市名称’,
receive_district_id varchar(32) DEFAULT ‘’ COMMENT ‘收货区县编码’,
receive_district_name varchar(64) DEFAULT ‘’ COMMENT ‘收货区县名称’,
receive_address varchar(128) DEFAULT ‘’ COMMENT ‘收货详细地址’,
push_tenant_code varchar(32) DEFAULT NULL COMMENT ‘推送方租户编码’,
push_instance_code varchar(32) DEFAULT NULL COMMENT ‘推送方实例编码’,
push_region_code varchar(32) DEFAULT NULL COMMENT ‘推送方区域编码’,
push_region_name varchar(32) DEFAULT NULL COMMENT ‘推送方区域名称’,
c_table varchar(10) DEFAULT NULL,
c_schema varchar(10) DEFAULT NULL,
c_source varchar(10) DEFAULT NULL,
PRIMARY KEY (order_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT=‘订单附属表’;
这个order_id的值是MD231009000404 年月日加几位数字, 另一个表sale_order也一样 是order_id主键

[有猫万事足]

你分表的主键是

PRIMARY KEY (order_id ) USING BTREE

分片键是

region_code varchar(32) DEFAULT NULL COMMENT ‘区域编码’,

你合表的主键就应该是

PRIMARY KEY (order_id,region_code ) USING BTREE

这种联合主键。

建议先把合表的主键改成这种联合主键，再试一下还有没有这个错误。

[AC米兰的铁匠]

感谢回复~
试了下,这样过不去, region_code定义的是DEFAULT NULL不能加到主键
我把dm集群降到7.5.3正在导入, 周一来应该就跑完了

[有猫万事足]

分片键怎么还会为null呢？我有点想不通，是不是分片键弄错了？

[AC米兰的铁匠]

很难理解, region_code按区域分应该是没有空值的, 这建表搞得是default null, 无语
现在换7.5的后又是其他报错, 一个Lightning:Restore:ErrRestoreTable]restore table gaia_order.t_order_detail_log failed: [gaia_order.t_order_detail_log]
batch write rows reach max retry 3 and still failed: Error 9005 (HY000): Region is unavailable.
看了集群没什么异常, 用9005在dashboard搜了下看不出来啥, 尝试重新start-task还是这.

另个是重复键Duplicate entry ‘219863737791299585’ for key, 重复是因为有个库的个别物料要同步到一个代仓库去…[个别物料…], 我也是服了

[有猫万事足]

Region is unavailable.这是个经典错误。不太可能集群同时没有任何异常。

专栏 - Region is unavailable的排查总结 | TiDB 社区

你看看这个。

[AC米兰的铁匠]

这里过去了, 应该不是tikv有什么问题. 错误更新了

Lightning:Restore:ErrRestoreTable]restore table `gaia_order`.`t_order_detail_log` failed: [`gaia_order`.`t_order_detail_log`] write rows exceed conflict threshold: Error 1136 (21S01): Column count doesn't match value count at row 1.

"progress": "98.44 %",
"stage": "Paused",
"unit": "Load",

差最后的1.5%, 搜了下git上有人遇到同样问题Column count match
这个表结构

CREATE TABLE `t_order_detail_log` (
  `order_detail_id` varchar(25) CHARACTER SET utf8 NOT NULL COMMENT '订单日志id',
  `region_code` varchar(50) CHARACTER SET utf8 DEFAULT NULL COMMENT '区域编码',
  `region_name` varchar(50) CHARACTER SET utf8 DEFAULT NULL COMMENT '所属区域',
  `order_type` varchar(64) DEFAULT NULL COMMENT '订单类型',
  `order_id` varchar(32) CHARACTER SET utf8 DEFAULT NULL COMMENT '订单编号',
  `operation_status_end` varchar(30) CHARACTER SET utf8 DEFAULT NULL COMMENT '操作后状态',
  `operation_status_start` varchar(30) CHARACTER SET utf8 DEFAULT NULL COMMENT '操作前状态',
  `operator` varchar(30) CHARACTER SET utf8 DEFAULT NULL COMMENT '操作人',
  `operation_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '操作日期',
  `note` varchar(50) CHARACTER SET utf8 DEFAULT NULL COMMENT '记录当前操作',
  `c_table` varchar(10) DEFAULT NULL,
  `c_schema` varchar(10) DEFAULT NULL,
  `c_source` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`order_detail_id`) USING BTREE,
  KEY `order_id` (`order_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;

你前面说的id和region_code联合主键应该是最优解, 可惜这个表里region_code都默认了null

[有猫万事足]

如果按你说的，上游的库里这个字段都有值，我觉得下游，你可以把这个 DEFAULT NULL去掉。
只要上有没有脏数据就行。
其实按照分片键的要求来说，这里不太需要DEFAULT NULL，可能是建表的时候，语句直接copy了。

[AC米兰的铁匠]

我刚就想说, 那我给删了试一下