在dm通过binlog的通过过程中，出现执行sql的时候提示表不存在
查询上下游的表列表，发现确实没有该表。
但是在排查上游mysql的binlog日志时，却有该表的sql执行语句，并且在上游执行完成：
上游mysql的日志格式为ROW以及binlog_row_image=FULL。
查询上下游的表列表，发现确实没有该表。
但是在排查上游mysql的binlog日志时，却有该表的sql执行语句，并且在上游执行完成：
上游mysql的日志格式为ROW以及binlog_row_image=FULL。
你好，
你的意思是上下游都没有这个表。
但是 binlog 中存在？
可否查询下贵司系统的操作记录，看下是否是误删除了？
这些都排查过来 确实没有这个表，也没有误删，但是binlog中就是有这个表。不知道是不是mysql什么设置吗？
你一楼的问题没太看懂，问题是否可以抽象为
mysql 执行 insert into 语句成功，但是 dm 报错，table 不存在。
查看 tidb 下游，发现这个表确实不存在。
不是insert into语句 是上游执行成功了delete from，而下游执行时报错。
ok，除了操作，还有其他描述有问题吗。
再确认下该表的创建方式。以及上游 mysql 的版本。在命令行执行 status 上传下返回。
mysql 中执行
select * from information_schema.`TABLES` where table_name = 'tbl' and table_schema = 'db'
看下该表的创建时间。
并且检查程序中是否有使用特殊 sql，将此 create table 语句没有记录到 binlog 中，导致 binlog 中记录该表的。
可以先将此表修复下：
基本思路是在现有 task 中过滤掉该表，
重新开一个 task
将此表全量增量同步下
检查 dm-meta 数据库，对比两个 task binlog file 和 pos 点位，确定新 task pos 大于 旧task。
先停 old task 防止其继续复制，将过滤条件去掉，完成 task 合并。
在 asktug 也有 task 合并的 FAQ，可以先搜索下。
select count(*) from db.tbl;
可以尝试做以下排查：
1、 确认一下初始化配置时候，TiDB 集群是否有该表，已经完成全量同步
2、如果这个表不存在，而且是全量同步确认无误，可以查看历史 DDL 操作确认一下这张表是否曾经被 drop table ；
查看历史 DDL 操作
curl http://{TiDBIP}:10080/ddl/history
ddl被过滤了。
不是通过 DM DDL 记录是下游 TiDB 的 DDL 历史记录，看看有没有做过 drop table 操作。
找个事业务自动生产的表，由于过滤了上游的ddl，所以tidb会找不到表。谢谢！
ok~
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。