After upgrading to MariaDB 11.4.1, the canal module stopped detecting row updates within transactions due to incorrect handling of fake rotate events. MariaDB 11.4.1 does not set LogPos for certain events, causing these events to be ignored. This fix modifies the handling to consider fake rotate events only for ROTATE_EVENTs with timestamp = 0, aligning with MariaDB and MySQL documentation.
Consequences of this change:
Events with LogPos=0 that are not of type ROTATE_EVENT will no longer be ignored.
If a database does not set timestamp=0 for fake rotate events, these events will be processed as real rotate events.
For MariaDB 11.4, I have confirmed that the timestamp for fake rotate events is set to 0. Based on the MariaDB and MySQL source code and documentation, I believe we can rely on this behavior.
I am not aware of any other events with LogPos=0 that should be ignored. Originally, this code was intended exclusively for handling fake rotate events and was not meant to ignore other events. Therefore, I believe this change is safe and will not negatively impact the processing of other binlog events.
After upgrading to MariaDB 11.4.1, the canal module stopped detecting row updates within transactions due to incorrect handling of fake rotate events. MariaDB 11.4.1 does not set LogPos for certain events, causing these events to be ignored. This fix modifies the handling to consider fake rotate events only for ROTATE_EVENTs with timestamp = 0, aligning with MariaDB and MySQL documentation.
Consequences of this change:
For MariaDB 11.4, I have confirmed that the timestamp for fake rotate events is set to 0. Based on the MariaDB and MySQL source code and documentation, I believe we can rely on this behavior.
I am not aware of any other events with LogPos=0 that should be ignored. Originally, this code was intended exclusively for handling fake rotate events and was not meant to ignore other events. Therefore, I believe this change is safe and will not negatively impact the processing of other binlog events.
Fixes #893
@lintanghui @csuzhangxc @gaojijun