binlog位点前移，ddl操作丢失
canal 版本：1.0.25 手动设置cursor的timestamp至 t1，当前时间为t2，t2 > t1 如果t1~t2这段时间之内产生了ddl 操作，binlog 位点前移至t1，重新消费这段时间的binlog，ddl操作丢失
canal server log 如下： canal.parse.inbound.mysql.tsdb.DatabaseTableMeta - dup apply for sql : CREATE TABLE canal.parse.inbound.mysql.tsdb.DatabaseTableMeta - dup apply for sql : alter table screen_fee add
原提问者GitHub用户yueapple
写回答
-
这不是ddl丢失，而是回到了T1时间之后，在重新解析发现在t1 -> t2中有ddl，重新加入到tsdb中发现已经加过了
原回答者GitHub用户agapple
2023-05-10 09:58:17赞同 展开评论 打赏 -
随心分享，欢迎友善交流讨论：）这个问题是因为在手动设置cursor的timestamp之后，Canal没有正确地重新定位到对应的binlog位置，导致在这个时间段内的DDL操作被丢失了。可能是因为Canal在重新定位binlog位置时出现了错误，或者是因为Canal对于某些DDL操作的解析不正确，导致这些DDL操作没有被正确地处理。
解决这个问题的方法有如下几个：
检查Canal的配置文件，确认是否正确设置了binlog的位置和起始时间戳。可以在Canal的conf文件夹下找到instance.properties文件，查看其中的binlog相关的配置，确保配置正确。
查询MySQL数据库的binlog日志，查看在手动设置cursor的timestamp之后，是否存在对应的DDL操作。如果存在，可以尝试手动执行这些DDL操作，恢复到正确的状态。
升级Canal的版本。针对DDL操作丢失的问题，Canal的新版本可能已经做了优化，可以尝试升级到最新版本。
对于无法恢复的数据丢失，可以考虑备份MySQL数据库并进行数据恢复，或者从其他渠道获取缺失的数据，进行数据补齐。
需要注意的是，由于Canal的设计和实现都比较复杂，这个问题的具体原因可能比较多，需要结合具体的环境和情况进行分析和解决。
2023-05-09 10:34:33赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
