Does go-mysql support HEARTBEAT_LOG_EVENT_V2?

[JasonMing]

Since MySQL 8.0.28, a new binlog type HEARTBEAT_LOG_EVENT_V2(41) was added for support >4GB single file.(https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-bug)

However, the replication.EventHeader.LogPos is still a uint32 until the report time(v1.13.0).

[lance6716]

Thanks for reporting. We didn't know this problem, will check later

also cc @dveeden

[dveeden]

@JasonMing I think the fix for this is probably straight forward. Do you want to try to create a PR for this?

[dveeden]

We have the constant for this (HEARTBEAT_LOG_EVENT_V2) in the code (added in 29ab7e7).

The text from the release notes linked above:
"Replication: The replication receiver thread stopped with an error if the replication source server sent a heartbeat event containing a binary log file position that was above the 4GB offset, due to the large size of the binary log file. A new heartbeat event (Heartbeat_log_event_v2, log event type 41) that handles the larger value correctly has been added for use in this situation. (Bug #29913991)"

There doesn't seem to be much more info than this.

So this would be a log position of >4GiB.

Might be good to first make this return a clear/obvious error and then make this support log positions larger than math.MaxUint32.

Looking at the code I don't think we really decode the heartbeat events. Maybe we should? We probably should check if we support binlog files of >4GiB in general.

Weirdly enough max_binlog_size has a max setting of 1GiB.

Maybe a 1>GiB file happens when a single transaction and/or row takes up a lot of space. Note that inserting a single large (longblob) column probably doesn't event do this as this is limited to max_allowed_packet (max 1GiB). But with using the API for long data this may be able to insert a value of close to the 4GiB. maybe a table with two longblob fields?