<p>MySQL replication stopped because the replica read a corrupted event in the master binary log.</p>
<p>MySQL Error 1610: ER_SLAVE_CORRUPT_EVENT means the replica encountered a damaged binary log event and stopped applying changes. Skip the bad event or rebuild the replica from a clean backup, then restart replication.</p>
Corrupted replication event was detected
MySQL raises error 1610 ER_SLAVE_CORRUPT_EVENT when a replica thread reads a binary log event that fails checksum or format validation. The server stops applying changes to protect data integrity.
The error shows in the replica error log and the Last_SQL_Error field of SHOW SLAVE STATUS. Replication remains stopped until the corrupted event is handled.
Quick resolution is vital because replication lag can cause stale reads, inconsistent analytics, and application failures in sharded or read-scaled environments.
Most cases trace back to an invalid or partially written event in the master binary log. Disk faults, power loss, or network drops can corrupt the file before it is shipped to replicas.
Version mismatches or bugs that generate malformed row events can also trigger the error. Upgrading one node without proper compatibility checks often introduces edge-case format issues.
First, locate the failing log position with SHOW SLAVE STATUS. Decide whether to skip the event, replace the log file, or rebuild the replica from a fresh snapshot.
For small data gaps, skipping a single event is faster. For repeated corruption, it is safer to re-clone the replica or rotate binary logs on the source.
If only one replica stops, corruption likely occurred in transit. Re-sync that replica. If all replicas halt at the same position, the master binlog is damaged; rotate logs and fail over if required.
During major version upgrades, ensure you enable binlog_checksum and use the same row-based format on all nodes to avoid format drift.
Enable binary log checksums, place binlogs on reliable storage, and use replication heartbeat to detect lag quickly. Automated backups and periodic replica rebuilds ensure fast recovery.
Monitoring tools like pt-table-checksum validate that replicas stay in sync after you fix the corrupted event.
Errors such as ER_SLAVE_FATAL_ERROR (1593) and ER_SLAVE_RELAY_LOG_READ_FAILURE (1594) also stop replication. They differ in root cause but are fixed with similar skip, relay-log purge, or rebuild steps.
Network or disk faults flip bits in the binary log, leading to a CRC mismatch detected by the replica.
Power loss or crash interrupts a binlog write, producing a truncated event propagated to all replicas.
Bad sectors on the replica host damage relay logs during write or read operations.
Different binlog_format or disabled checksum on master versus replica generates unreadable events.
Edge cases in certain MySQL or MariaDB versions create malformed row events that replicas reject.
Generic fatal replication error that stops both I/O and SQL threads. Often fixed by full rebuild.
Replica cannot read relay log due to corruption on disk. Purge or recreate relay logs.
Replica I/O thread cannot read master binlog, usually due to missing or purged file.
User issued STOP SLAVE UNTIL; replication waits for specific position or GTID.
Yes, skipping discards one statement or row set. Confirm the change is safe or apply it manually.
Check SHOW SLAVE STATUS on each replica. If they stop at the same log and position, the source binlog is corrupted.
Galaxy surfaces replication lag metrics in the editor sidebar, alerting engineers when SQL threads stop and letting them run corrective commands quickly.
Checksums catch most corruption but cannot fix hardware faults. Combine with ECC storage and regular backups for full protection.
.avif)
.avif){kind=logo}
