在dm通过binlog的通过过程中,出现执行sql的时候提示表不存在
查询上下游的表列表,发现确实没有该表。
但是在排查上游mysql的binlog日志时,却有该表的sql执行语句,并且在上游执行完成:
上游mysql的日志格式为ROW以及binlog_row_image=FULL。
在dm通过binlog的通过过程中,出现执行sql的时候提示表不存在
你好,
你的意思是上下游都没有这个表。
但是 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 分钟后被自动关闭。不再允许新回复。