<p>Replication stopped because the master recorded a critical INCIDENT event in its binary log.</p>
<p>MySQL Error 1590: ER_SLAVE_INCIDENT means the replica received an INCIDENT event that the master wrote after detecting corruption or another unrecoverable issue. Replication halts to protect data. Inspect the master’s binary log, correct the root problem, then skip or re-apply the event and restart replication.</p>
ER_SLAVE_INCIDENT
Error 1590 with SQLSTATE HY000 fires when a replica encounters an INCIDENT event in the master's binary log. The message The incident %s occurred on the master indicates the master stopped normal logging because it detected corruption or an unrecoverable condition.
The replica surfaces ER_SLAVE_INCIDENT immediately after reading the INCIDENT event. At that point replication threads stop, Seconds_Behind_Master becomes NULL, and application queries may lag against stale data.
While the replica is stopped, failover, read scaling, and disaster-recovery objectives are at risk. Ignoring the incident can let hidden corruption spread if the replica is later promoted.
MySQL inserts the INCIDENT event type into the binary log whenever it detects a failure it cannot represent with normal log events-for example, corrupted pages while flushing a transaction or a missing tablespace file.
Galaxy’s version-controlled query history and instant visibility of replication status help engineers detect ER_SLAVE_INCIDENT quickly. The AI copilot can also suggest the exact CHANGE MASTER or SET GLOBAL sql_slave_skip_counter commands to resume replication once the root issue is fixed.
Disk faults or abrupt crashes can damage the master’s binlog, forcing MySQL to write an INCIDENT event.
Checksum failures during flush or recovery trigger an INCIDENT so downstream replicas do not read bad data.
Dropping or renaming files outside MySQL causes an unrecoverable condition that MySQL records as an INCIDENT.
Edge-case DDL or storage-engine bugs may lead the server to abort logging with an INCIDENT event.
Occurs when a replica cannot read a binary log event, often due to log rotation or truncation.
Replicas stop because the row they need to update or delete is missing.
Raised when the replica cannot read master info files at startup.
Indicates relay log corruption on the replica rather than an issue on the master.
Use mysqlbinlog on the master at the Relay_Master_Log_File and Exec_Master_Log_Pos reported by SHOW SLAVE STATUS. The INCIDENT event appears with a readable description.
The INCIDENT itself contains no data changes, so skipping it does not drop rows. You must still repair any corrupted tables to ensure consistency.
Yes. The INCIDENT event carries a GTID like any other transaction. Skip it with SET GTID_NEXT = 'AUTOMATIC' and sql_slave_skip_counter.
Galaxy cannot stop physical corruption, but its monitoring panels surface replication lag instantly, and its AI copilot suggests the exact SQL to resume replication after you fix the master.
.avif)
.avif){kind=logo}
