DM dump阶段产生的SQL文件，是否能增加 drop 语句

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】

MySQL Server version: 5.7.22-log MySQL Community Server (GPL)
tidb： v4.0.11
dm：  v2.0.1

【问题描述】

%E5%9B%BE%E7%89%87979×197 30.8 KB

需求：
TiDB作为MySQL的从库，使用DM迁移任务完成。因为业务需要，研发会在TiDB从库创建一些表，这些表的数据要保留。这样TiDB上就有了MySQL主库的数据 + 研发自建的数据。
然而，目前TiDB有部分DDL语句不支持，会导致DM同步中断，这时候，我们需要重新同步MySQL数据到TiDB（全量+增量方式），这时，必须先删除TiDB中已存在的数据（MySQL部分）；否则无法正常同步（比如主键冲突等）。
这就有两种处理方式：1）手动删除TiDB中MySQL数据部分，保留研发自建部分。2）如果dump语句有“DROP table IF EXISTS table_name”这样的子句（dump文件如上图），就无需先手动删除了，直接重新同步即可。

请问，DM task 的配置文件中，是否有支持此功能的配置项？（我查看[https://docs.pingcap.com/zh/tidb-data-migration/stable/task-configuration-file-full#完整配置文件示例]没找到）
烦请指导，谢谢。

同步中断之后的解决方式，使用 handle-error 跳过这个 DDL就好了。另外该 DDL 如果是必须的，可以在下游 TiDB 中创建临时表并导入原表数据，之后进行 rename 操作。

https://docs.pingcap.com/zh/tidb-data-migration/stable/handle-failed-ddl-statements#handle-error

上述需求可以使用 sync diff 工具对比上下游数据的情况，研发自建部分数据是上游不存在的。
https://docs.pingcap.com/zh/tidb/stable/sync-diff-inspector-overview#sync-diff-inspector-用户文档

如果遇到 TiDB 不支持的 DDL 导致 DM 同步中断，不需要每次都重新同步，这样成本太高了，可以考虑参考下面的方式来处理不兼容的 DDL ：
https://docs.pingcap.com/zh/tidb-data-migration/stable/handle-failed-ddl-statements

嗯，目前如果出现个别DDL导致的同步异常，的确是使用 handle-error 处理的。
但是，我们研发库会有大量DDL更新，而且还会遇到 insert 语句、key重复等导致同步异常的情况，而这些情况如果时时关注，并且使用上述方式处理，太耗时间与人力成本。通常我们是每天下班后重新跑一次同步解决。（非生产环境）
再加上，我们版本迭代比较快，每个大版本都会有大量DDL语句，而像数据类型的修改，还是比较常见；TiDB从库数量也有近50个左右，所以像这种“大改动”，我们倾向于重新同步解决。这种重新同步，虽然不是天天有，但是每月肯定有个一两次。（生产环境）
如上，所以我才想确认下是否有支持此功能的配置项。

嗯，谢谢。这个处理方式我知晓。具体回复请见上楼回复。

大量不支持的 DDL 建议在 task 中配置 binlog filter，提前过滤掉。
https://docs.pingcap.com/zh/tidb-data-migration/stable/key-features#binlog-event-filter

好的，感谢。这个我了解下。
请问，我帖子提到的问题呢，是否支持？

问题：全量同步时，dump阶段生成的SQL文件，是否可以多一行“DROP table IF EXISTS table_name”这
     样的子句。
     也就是，创建表前，若表存在则先删除之。是否有选项支持开启此功能？

没有。

好的，感谢解答。
那我就只能写脚本实现先删除数据表了。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。