Analyzing MySQL Replication Heartbeat Incompatibility Caused by Large Binlog Transactions

This article examines a recurring MySQL replication error that occurs at year‑end when large batch transactions cause the replication heartbeat to fail with the message “heartbeat is not compatible with local info”.

First, the authors recreate the problem by setting up a master‑slave pair, creating a 500 MB empty file, and building a table with a LONGBLOB column to generate a massive binlog (approximately 32 GB) containing two transactions, each larger than 4 GB.

During replication, the slave is forced to start receiving data from the middle of the large binlog (transaction 26). The IO thread soon reports the same heartbeat error observed in production.

Through packet capture with tcpdump and analysis in Wireshark, the authors map the captured packets to MySQL’s protocol specifications, focusing on the binlog event header. They discover that the next_position field in the heartbeat packet is only 4 bytes, limiting its maximum value to 2³¹‑1 (≈4 GB). When the actual binlog position exceeds this limit, the value overflows, causing the reported position to be smaller than the current one.

The overflow triggers the heartbeat validation logic, which treats the decreasing position as an incompatibility and aborts replication.

Two mitigation approaches are suggested: (1) avoid creating oversized transactions, as MySQL is not designed for them; (2) disable the heartbeat mechanism, which hides the symptom but reduces fault‑tolerance and is therefore not recommended.

The article concludes with a recap of the findings, practical tips for locating problematic packets in captures, and references to related MySQL bug reports.