GTID-SET的值怎么是全0？这个是没有做全量同步，直接用增量同步搞的？
可以发下任务配置么？(注意删除一下密码相关信息)
stop task，修改配置文件，safe mode true，再启动
我这是双写了，跳过冲突啊
落后32w秒，这要追3-4天的进度了。
这个跳过，后面不太好吧，建议还是解决哈
实时数据不多，很快追上
1 个赞
不跳过，如何解决？有无好的思路
tidb删除该注解，然后resume-task一下任务
问题很多条冲突的？
跳过这个错误就行了。
具体语句？
和我执行的又啥不同？
不跳过就得手动处理数据
冲突的原因是什么？
是delete/truncate/drop这类事件中有个没同步？
如果不想同步上游drop/truncate这类ddl，又要不出现主键冲突。
推荐打开safe_mode.
https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full
syncers: # sync 处理单元的运行配置参数
global: # 配置名称
worker-count: 16 # 应用已传输到本地的 binlog 的并发线程数量，默认值为 16。调整此参数不会影响上游拉取日志的并发，但会对下游产生显著压力。
batch: 100 # sync 迁移到下游数据库的一个事务批次 SQL 语句数，默认值为 100，建议一般不超过 500。
enable-ansi-quotes: true # 若 `session` 中设置 `sql-mode: "ANSI_QUOTES"`，则需开启此项
# 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。
safe-mode: false
注意syncers配置下面有个safe-mode设置为true就可以了。
tiup dmctl:v5.4.0 binlog skip taskName -b mysql-bin000003:3270跳过特定的binlog event就可以了
知道这个设置，就是想了解哪些情况出了问题，才让报错的。
这不是和我的方式一样吗？
个人理解，DM 中所有的跳过操作，无论是低版本的 handle-error，还是 binlog skip
最初的目的都是为了跳过 DDL 语句的，例如一些 DM 上游支持，目前 TiDB 还不支持的语句，这是比较正确的用法。
https://docs.pingcap.com/zh/tidb/v7.3/handle-failed-ddl-statements#binlog
对于主键冲突的这种场景，正常情况下，是不应该存在的。如果存在的话，就需要您这边自行确认数据是否保留。
双写是指
一份数据写入 DM 的上游库，然后通过 DM 同步到 TiDB
另一份数据直接写入 TiDB 吗？
不太理解这样做的目的是什么，如果是这种方式，那为什么还需要 DM 同步啊？
迁移前线上数据实测啊
测试tidb也处理一遍线上的业务，线上mysql继续做线上的业务处理。