MySQL raises ER_INCONSISTENT_ERROR (3002) when a statement produces different errors on the primary (master) and replica (slave), breaking binary log consistency and halting replication.
ER_INCONSISTENT_ERROR (3002) means a query failed differently on master and slave, stopping replication. Align schemas, skip the inconsistent event, and restart replication to fix the issue.
ER_INCONSISTENT_ERROR
MySQL throws ER_INCONSISTENT_ERROR (code 3002, SQLSTATE HY000) when a binary logged statement fails with one error on the primary server but triggers a different error on the replica. The mismatch breaks deterministic replication guarantees, so MySQL stops the SQL thread to prevent data drift.
The error text lists both messages and error codes, the default database, and the failing query. Because the event already executed on the master, ignoring it on the replica can create divergence, so you must diagnose quickly.
Most cases trace back to schema or data differences between master and replica. If a column exists on one server but not the other, an UPDATE may succeed on the master yet fail with ER_BAD_FIELD_ERROR on the replica, triggering ER_INCONSISTENT_ERROR.
Other triggers include non-deterministic functions, unsafe SQL modes, executed triggers that differ between nodes, or a replication delay that let DDL run in a different order. Hardware faults and corrupted relay logs can also produce mismatched errors.
First, stop the SQL thread to freeze the replica state. Inspect the failing query and compare schemas and data between master and replica. Align them, then either skip the bad event or rebuild replication.
Use CHANGE MASTER TO MASTER_AUTO_POSITION to restart if you use GTID, or execute SET GLOBAL sql_slave_skip_counter = 1 for classic replication. Always verify consistency with checksums before resuming traffic.
When a column is missing on the replica, run an ALTER TABLE to add the column, then start slave. If data divergence is suspected, dump data from the master and import it into the replica, or run pt-table-checksum followed by pt-table-sync.
For corrupted relay logs, run STOP SLAVE; RESET SLAVE RELAY LOGS; START SLAVE; to fetch a fresh copy. If the error stems from unsafe non-deterministic statements, convert them to row-based logging.
Always use row-based replication for workload with side-effects. Deploy schema migrations through orchestrated pipelines so DDL executes in the same order on all nodes. Enable OBJECT_CHECKSUM in Galaxy or your CI pipeline to block drift before code reaches production.
Monitor SHOW SLAVE STATUS and performance_schema.replication_applier_status to catch replication stops early. Automate checksums nightly and test backups to guarantee a fast restore path.
ER_DUP_ENTRY (1062) often appears when replicas diverge on unique keys. ER_BINLOG_UNSAFE_STATEMENT warns of statements that could later manifest as ER_INCONSISTENT_ERROR. ER_SLAVE_FATAL_ERROR (1593) is a generic replication stop that may wrap this error.
Each requires comparing master and replica state, aligning data, and restarting replication with consistency checks.
Tables, columns, or indexes differ because a DDL ran manually on one server.
Statements that depend on UUID(), NOW(), or unordered SELECT can behave differently.
Disk issues or crashes damage relay logs, leading to misparsed events.
Different definitions cause divergent side-effects and errors.
Unique key violation can halt replication similarly.
Generic fatal replication error that wraps low-level issues.
Warning that statement-based logging may diverge.
Ignoring without fixing the root cause risks silent data divergence. Always investigate, align, and verify before skipping events.
Row-based replication removes many nondeterministic pitfalls, greatly reducing but not fully eliminating the risk.
Galaxy highlights schema diffs in the editor, integrates pt-table-checksum, and lets teams endorse safe migration queries to prevent drift.
For large drift or unclear root causes, restoring from a fresh backup or clone is often safer and quicker than manual sync.