读取后记录的是事务结束的开始positon,而不是end_log_pos

环境信息

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:

提问240.png

期待结果

按照正常的想法,meta.dat中记录的应该是6201吧

原提问者GitHub用户LuVx21

展开

收起

古拉古拉 2023-05-08 13:55:19 75 0

2 条回答

写回答

取消提交回答

函数计算小白

位点记录的的确是最后一个事件的开始position，设计上的问题

原回答者GitHub用户agapple

2023-05-09 17:50:01

赞同展开评论打赏
LittlePenguin

随心分享，欢迎友善交流讨论：）

根据您提供的信息，您在使用 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 在不同的版本中可能存在一些兼容性问题或者性能瓶颈，您可以参考官方文档或者社区贡献者的建议，来选择合适的版本和参数配置。

希望以上信息能够帮助您解决问题。

2023-05-08 14:13:55

赞同展开评论打赏