环境信息
canal version 5.6 mysql version canal.deployer-1.1.2
问题描述
1、循环读取binlog时, 某个事务的事务结束事件(假设为a)也读取到并处理掉了(后续循环是空循环,不再读取到新的binlog),
2、但meta.dat中记录的是这和事务结束的开始position,
3、此时停止canal,再次启动后,运行client代码,会将a事件(事务结束事件)再读取一次
效果大致如下图: meta.dat
"postion": {
"gtid": "",
"included": false,
"journalName": "mysql-bin.000019",
"position": 6170,
"serverId": 1021,
"timestamp": 1551686429000
}
binlog:
mysql-bin.000019 5834 Query 1021 5906 BEGIN mysql-bin.000019 5906 Rows_query 1021 5999 # UPDATE boot
.user_xxxxx
SET password
= 'barfoo' WHERE id
= 2 mysql-bin.000019 5999 Table_map 1021 6063 table_id: 76 (boot.xxxxx) mysql-bin.000019 6063 Update_rows 1021 6170 table_id: 76 flags: STMT_END_F mysql-bin.000019 6170 Xid 1021 6201 COMMIT /* xid=356 */
重启canal后再次运行client:
期待结果
按照正常的想法,meta.dat中记录的应该是6201吧
原提问者GitHub用户LuVx21
根据您提供的信息,您在使用 Canal 读取 MySQL binlog 数据时,发现事务结束事件记录的是开始 position 而非结束 position,导致在重启 Canal 后,事务结束事件被再次读取。这个问题可能是由于 Canal 的处理逻辑或者 MySQL binlog 的格式导致的。
首先,您需要确认 MySQL binlog 是否包含完整的事务信息。由于 MySQL binlog 采用基于语句的复制方式,而非基于行的复制方式,因此可能会存在一些特殊情况,例如事务被提交后未写入 binlog、binlog 文件被截断等情况,导致 Canal 无法正确解析事务结束事件的位置。您可以使用 mysqlbinlog 工具来检查 binlog 文件,以确定事务结束事件的位置和格式是否正确。
其次,您需要检查 Canal 的配置文件和处理逻辑,以确定是否存在 bug 或者配置错误导致的问题。例如,如果 Canal 配置文件中设置了过滤规则或者事务合并策略,可能会影响到事务结束事件的处理和记录。您可以参考 Canal 的官方文档,了解更多关于过滤规则和事务处理的信息。
最后,如果以上检查都没有发现问题,您可以尝试升级 Canal 的版本或者修改 MySQL binlog 的格式,以获得更好的稳定性和兼容性。Canal 在不同的版本中可能存在一些兼容性问题或者性能瓶颈,您可以参考官方文档或者社区贡献者的建议,来选择合适的版本和参数配置。
希望以上信息能够帮助您解决问题。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。