DM 版本8.1.0
求一个配置，修改冲突数。现在有冲突，但是因为上游是分库分表，数据可能就是有冲突，冲突忽略就行。
RawCause: [Lightning:Restore:ErrRestoreTable]restore table `xxxx`.`xxxx` failed: The number of conflict errors exceeds the threshold configured by `conflict.threshold`: '10000'.\n",
这个 conflict.threashold 配置在哪里？
这个我搜到了，但是我是配置的dm任务，从dm的配置里面怎么改这个？
你就按照lightning 这种样式配置的试试
写哪儿啊？来个例子？
不要修改这个参数的上限，除非你确保冲突就这么多，显然你现在确定不了。所以你改大这个参数等时间到了仍然会超过参数。
建议使DM用安全模式。
DM安全模式下insert into会被改写成replace into。冲突的数据就会用新的覆盖旧的。
syncers:
global:
worker-count: 64
batch: 500
compact: true
multiple-rows: true
safe-mode: true
safe-mode 已经是 true 了
我看看为什么冲突吧
经过检查，是分表有自增id作为主键。确实没法继续同步。
看来偷懒是不行的 
，直面问题。
自增主键忽略了呗，主键有实际意义吗，分库分表，有没有全局唯一识别字段
自增主键冲突，有两个解决办法，一个是，如果下游的自增ID 没有实际意义，直接取消掉primary属性，把他变成普通的index，前提是保证要有其他的全局唯一索引做约束，
另外一个就是 联合主键，然后再 task里面配置一个 1. ```
ignore-checking-items: [“auto_increment_ID”]
直接把下游的自增主键改成普通列了。这一列业务实际没用。同步的任务因为冲突暂停了，为了避免从头再来，选择新建别名表，处理好表结构，然后把数据通过 insert into select from 处理。然后重命名，最后再开始同步，可以继续向下走。避免重新load一遍。
insert into aaa select * from bbb;
rename table bbb to ccc;
rename table aaa to bbb;
阔以，没毛病这么干
https://docs.pingcap.com/zh/tidb/stable/dm-table-routing#提取分库分表数据源信息写入合表
为了提取上游分表来源信息数据以写入到下游合表，必须在启动迁移任务前手动 在下游创建好对应合表，合表需要包含用于存放分表源数据信息的三个扩展列
target-column（表名列、库名列、数据源列），扩展列必须为表末尾列且必须为字符串类型 。
这种情况如果硬要合也不是不可以，dm可以多添加3个字段标识上游数据源来自那个源/库/表。下游提前建表的时候，做个联合主键就行。
这种虽然麻烦了点，优点就是好溯源。不然万一那天怀疑这个表同步有问题，缺乏主键的表就很难溯源了，搞不清楚是哪里出了问题。
如果不需要溯源，确实是直接去掉主键约束最好。
强大！我就是一开始偷懒了，我感觉冲突肯定是我们的分库分表没把数据弄干净，导致多个库里面有重复数据，想改吧改吧参数忽略了。经猫神一提醒，确实得好好查查！
还有就是这个功能有个bug。如果上游执行了create table if not exists这种建表语句，会导致dm认为下游的表结构也应该是没有这3个字段的。
也就是说上游执行create table if not exists，会覆盖dm记录的下游表结构的元数据，哪怕配置是需要这3个字段的，哪怕上游实际没有建表。然后导致同步卡住。
所以你用这个功能还需要注意上游不要执行create table if not exists。
如果执行了，看下面这个帖子。需要手动的改回来，如果上游频繁的这么搞，是比较烦的。
通过ddl过滤掉create table if not exists也是一个办法。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。