<p>The replica SQL thread stops because its data diverges from the primary while applying events in multi-threaded replication.</p>
<p>MySQL Error 1756: ER_MTS_INCONSISTENT_DATA means the replica found data or DDL that differs from the primary and halted to preserve consistency. Re-checksum the affected table, resync it with mysqldump or pt-table-sync, then START SLAVE to resume replication.</p>
%s
The error appears in the replica error log and SHOW SLAVE STATUS when the multi-threaded SQL applier detects a row or schema difference compared with the primary server.
MySQL halts replication immediately to avoid propagating corrupt or conflicting data. The SQL thread stops, the IO thread may continue, and Seconds_Behind_Master grows.
During multi-threaded replication, transactions can execute in parallel. The applier performs sanity checks before each event. If a row-based image does not match the expected state, or a DDL tries to alter an already divergent object, MySQL raises ER_MTS_INCONSISTENT_DATA.
The safeguard prevents hidden divergence that would break point-in-time recovery, failovers, or analytics derived from the replica.
Direct writes on the replica, non-deterministic statements on the primary, or skipped GTIDs commonly create mismatch. Inconsistent logical backups restored to replicas also trigger the error.
Hardware crashes, incomplete schema migrations, or row corruption can alter replica pages, leading MySQL to flag the difference on the next replicated event.
First, identify the failing database, table, and binlog position with SHOW SLAVE STATUSG; review Last_Error and Relay_Master_Log_File.
If only one table is affected, re-export it from the primary: FLUSH TABLE tbl READ LOCK; mysqldump tbl; import on replica; then UNLOCK TABLES; finally START SLAVE;
For widespread drift, rebuild the replica: STOP SLAVE; RESET SLAVE; clone data with mysqldump, MySQL Clone, or XtraBackup; CHANGE MASTER TO MASTER_AUTO_POSITION=1; START SLAVE;
Scenario: an application mistakenly writes to a read-only replica. Solution: set read_only=1 and super_read_only=1, revoke WRITE privileges, and resync the changed tables.
Scenario: statement-based replication sent NOW() or RAND() causing different values. Switch to row-based format on the primary and refresh the replica.
Enable row-based replication, enforce read_only and super_read_only on replicas, and monitor for ERRORS in the replica error log.
Regularly run pt-table-checksum or MySQL CHECKSUM TABLE from Galaxy queries to detect drift early. Capture backups after clean STOP SLAVE to guarantee consistency.
ER_DUP_ENTRY (1062) may appear if replica rows already exist. ER_SLAVE_MUST_STOP (SLAVE FATAL) stops replication when vital errors occur. Both usually need similar resync steps.
User or application sessions insert, update, or delete rows on the replica, breaking deterministic replay.
Functions like NOW(), RAND(), or UUID() executed in statement-based mode generate different results on replica.
Manual GTID_PURGED edits or SET GLOBAL sql_slave_skip_counter can create holes that surface later.
Restoring a logical dump taken without --single-transaction allows drift if the primary was active.
Hardware or power failure modifies data pages on the replica only, leading to mismatched rows.
The replica cannot find a row needed for an update or delete; often a precursor to 1756.
The IO or SQL thread cannot read the relay log due to corruption or missing files.
The replica tries to drop or alter a table that does not exist, signaling schema drift.
Replication inserts a row whose primary key already exists; resync or skip may be required.
Yes. MySQL halts the SQL thread immediately to prevent further divergence until you intervene.
Skipping merely masks the problem. Resync the data instead to keep replica accuracy.
Row-based format eliminates many nondeterministic issues but cannot stop manual replica writes or corruption.
Galaxy lets you run checksum queries, share resync scripts, and enforce read-only configurations through audited SQL, reducing chances of drift.
.avif)
.avif){kind=logo}
