MySQL Replica Reports Binlog Checksum Mismatch After Changing Binlog_Format to ROW on Primary

Environment

Primary: MySQL 8.0.32 on Ubuntu 22.04 (binlog_format=ROW, binlog_checksum=CRC32), Replica: MySQL 8.0.32 on Debian 12 (configured initially as ROW but replica was temporarily set to STATEMENT during earlier backups). GTID-based replication used. TLS between nodes.

Symptoms

Replica I/O thread connects to primary but slave SQL thread stops applying events with error: 'Error reading from master: got error 1236: Could not find first log file name in binary log index file' and later shows 'relay log read failure: checksum mismatch' for several relay log files. Replication lags and then halts; SHOW SLAVE STATUS shows Last_SQL_Error mentioning 'Could not read event' and relay files appear shorter than on primary.

Observations

Primary's mysqlbinlog output for recent events matches expected ROW events. Replica's relay logs for the same time window differ in size and contain truncated events. Network traces show brief TCP resets between primary and replica during late-night backups of replica filesystem, coinciding with the time errors start. Replica's my.cnf had binlog_checksum=NONE previously and was recently changed to CRC32; relay logs created before the change are present and some checksums do not match.

Already attempted

Stopped and restarted replication threads, forced STOP SLAVE / START SLAVE, ran mysqlbinlog to validate primary logs, set replicate-wild-ignore-table temporarily, moved older relay logs out of datadir, tried CHANGE MASTER TO MASTER_LOG_FILE=..., MASTER_LOG_POS=..., but replica still reports checksum mismatch or event parse errors. Did not run a fresh full backup/restore yet due to dataset size.

Question

How can I safely recover replication given relay-log checksum mismatches after binlog_format/binlog_checksum changes and intermittent network resets, and what reversible diagnostics should I run before performing a full re-sync?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Partial relay log writes on the replica due to brief TCP resets or I/O issues while fetching binlog events, causing checksum failures when SQL thread reads them. 90%

Mismatch of binlog_checksum setting between primary and replica while relay logs were generated (replica created relay logs without checksum or with different CRC settings). 85%

Residual older relay logs from before config change causing replica to attempt to apply mixed-format or mismatched-checksum files. 70%

Summary

Checksum mismatch and truncated relay logs typically arise from network interruptions while fetching binlog events, differences in binlog checksum configurations between primary and replica at the time of fetch, or pre-existing relay logs left over from prior configuration changes. Because GTID is used, the safest recovery is to re-initialize the replica’s relay state from a consistent snapshot, but smaller fixes may be possible if corruption is limited to recent relay files.

Suggested Fixes

Diagnostic step 1

Record current GTID_EXECUTED and GTID_PURGED on both servers. Do not alter GTID sets yet—export them for reference.

Diagnostic step 2

On the replica, move existing relay logs to a safe backup directory (stop replication first), preserving them for forensic analysis. This is reversible by moving them back.

Diagnostic step 3

Ensure replica my.cnf binlog_checksum matches primary (set to CRC32) and restart mysqld if necessary—document change and restart impact on local writes.