1.用DM 消费上游mysql 分库分表的binlog，query-status 显示task正常，但并没有将上游的数据写入下游TIDB中，而且checkpoint表中check时间正常.
2.我想重新消费中断之前的binlog，应该如何操作更加稳妥，重新消费的过程中，是否会跳过主键冲突的值？
反馈下 dm 版本，tidb 版本
反馈下 query-status 信息。和 dm-worker.log 内容。这边看下
可以开启 task 文件中的 safe-mode 和 dm-meta 数据库下的位点
dm版本：dm-ansible-v1.0.6
tidb版本:
Release Version: v4.0.0
Edition: Community
Git Commit Hash: 689a6b6439ae7835947fcaccf329a3fc303986cb
Git Branch: heads/refs/tags/v4.0.0
UTC Build Time: 2020-05-28 01:37:40
GoVersion: go1.13
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
query-status.txt (2.3 KB)
dm-work.log日志太大了，我搜索了一下，没有发现error的信息
您说的safe-mode 模式，是怎么开启，在哪个地方设置，我看了文档，没找到
Safe mode
指增量复制过程中，用于支持在表结构中存在主键或唯一索引的条件下可重复导入 DML 的模式。
该模式的主要特点为将来自上游的 INSERT 改写为 REPLACE ，将 UPDATE 改写为 DELETE 与 REPLACE 后再向下游执行。在启动或恢复增量迁移任务的前 5 分钟 TiDB DM 会自动启动 Safe mode，另外也可以在任务配置文件中通过 safe-mode 参数手动开启
https://docs.pingcap.com/zh/tidb-data-migration/v1.0/glossary#safe-mode
在同步任务配置中为 syncers 部分设置 safe-mode: true 以保证可重入执行
https://docs.pingcap.com/zh/tidb-data-migration/v1.0/faq#同步任务当前处于-sync-阶段
修改这个safe-mode,我理解是不是要同时修改这几个地方：
1.对应的dm-worker下必须只有一个task，如果有多个task，多个任务都必须stop掉，否则relay.meta的文件信息还是会被最新消费的binlog点位覆盖
2.修改对应 dm-worker-deployDir/relay_log/{uuid.index-num}/relay.meta 文件，设定到指定的binlog信息点位，
3.要修改dm-meta 数据库下frxs_trade_order_info_syncer_checkpoint表里面的Binlog_name和binlog_pos这两个信息
4.在.yml文件中,syncers部分 增加 safe-mode:true
5.再重新启动start-task
relay log 是可以复用的，多个 task 对应以个 relay meta 文件，同步信息保存在 dm-meta 数据下的 sync 表中
yes
dm-worker 启动会先读取 relay meta 文件，所以 dm-meta 数据库下的数据不需要修改，此数据库中的信息也是 relay meta 文件中读取上去的
yes
是的
修改 relay meta 文件需要遵守
- stop.yml -l dm-worker01
- vi relay.meta
- start.yml -l dm-worker02
我在同一个dm-work下只配置了一个实例，但部署了多个task运行，但目前我在 dm-worker-deployDir/relay_log/{uuid.index-num}/ 下只发现了一个relay.meta,并没有多个，是不是我哪里搞错了？
tree relay_log 返回下结果。
cat relay.meta
ok，这边更下下，relay.meta 文件多个 task 对应一个。此文件保存拉取上游 binlog 的位置。如果想重新消费某个 task 的记录，需要修改 dm-meta 数据库下的 sync 相关的表的位点信息即可。并开启 safe mode 模式。待消费到最新时间点数据可以关闭 safe mode 此参数对同步效率有影响
“name”: “frxs_trade_order_info”,
“stage”: “Paused”,
“unit”: “Sync”,
“result”: {
“isCanceled”: false,
“errors”: [
{
“Type”: “ExecSQL”,
“msg”: “”,
“error”: {
“ErrCode”: 10006,
“ErrClass”: 1,
“ErrScope”: 0,
“ErrLevel”: 3,
“Message”: “execute statement failed: INSERT INTO frxs_trade_area.table1 (xx,xx,x,x,x,x,x,x,x,x,x,x,x,x,x,x ) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,…: Error 1062: Duplicate entry ‘20070600210201331711348146’ for key ‘PRIMARY’”,
“RawCause”: “Error 1062: Duplicate entry ‘20070600210201331711348146’ for key ‘PRIMARY’”
}
},
重复消费，遇到主键冲突的问题，这个是否可以通过配置文件，忽略掉嗯？
safe mode 是否已经开启了呢~
或者可以描述下当前的需求，我们看是否可以提供帮助
task任务中，safe-mode是开启
目前的情况是：
在同一个dm-work 我只配置了一个实例，但运行了多个task。
其中一个task1是 不用将上游的库表进行聚合，所以就单独运行。
task2是需要将上游的分库分表，在下游TIDB合成一张表进行同步，所以我通过咱们的DM portal 生成了yml文件，同时执行了task2，但同步了3天，发现中间只有1天半的数据进来了，最近1天半的数据没写进来，但task2任务又是正常的没有任何错误。
因此，我只能通过重复消费binlog，来补数据。所以才会有上述的那些问题。
safe-mode 开启需要 stop start task 使参数生效。
这个不建议盲目重复执行，可以看下当时的 dm-worker log 信息，看问题的原因是什么
这个是按照stop 然后再start，我不重复执行，那数据就不完整，只能重复消费Binlog。针对这块有没有可行的解决方案？
阿里的otter 可以重置到某个时间点的binlog，同时可以忽略掉重复消费产生的主键冲突，咱们是否可以考虑借鉴一下？
重启 dm worker 在 start task 试下
重启了，还是不行，执行过程还是报主键冲突，没办法重复消费。这个有没有可行的解决方案
还有这类 语法不支持怎么处理掉?
“isCanceled”: false,
“errors”: [
{
“Type”: “ExecSQL”,
“msg”: “”,
“error”: {
“ErrCode”: 10006,
“ErrClass”: 1,
“ErrScope”: 2,
“ErrLevel”: 3,
“Message”: “execute statement failed: ALTER TABLE sci.t_store MODIFY COLUMN tmsmp DATETIME: Error 8200: Unsupported modify column: type datetime not match origin timestamp”,
“RawCause”: “Error 8200: Unsupported modify column: type datetime not match origin timestamp”
}
},
不支持此类型的 ddl 变更，该语句在 tidb 中执行也是不通过的。
可以使用暂时跳过这个ddl ，https://docs.pingcap.com/zh/tidb-data-migration/stable/skip-or-replace-abnormal-sql-statements/
像这类 ： 跳过或替代执行异常的 SQL 语句
咱们DM有没有考虑在后期的版本迭代中，增加 选择 代码，只要用户输入Y/N，或者增加DM的UI界面，这样操作性，就更强，很轻松就可以完成这一操作。
目前使用DM上有些处理不是很清晰，有些坑，TIDB在mysql语法上做了处理，导致一些不兼容，但DM这块又不能自动处理掉，需要用户手动处理，感觉有些不是很友好。
似的，一些小的错误 dm 这边会自动处理，或者忽略，但是对于 ddl 等操作，还是有风险的。目前确实有些问题处理起来不是很方便，我们也在完善中，如果有好的建议或者用着不爽的地方请多多在 github dm 版块提交 issue 或者 pr 我们以此来评估下是否需要增加某些机制。
https://github.com/pingcap/dm