<p>The slave thread detected a temporary conflict and must retry the current transaction without raising a fatal replication error.</p>
<p>MySQL Error 1806 ER_SLAVE_SILENT_RETRY_TRANSACTION signals the replication slave to silently re-execute the current transaction due to a lock or conflict. Confirm innodb_lock_wait_timeout values, review conflicting writes, then restart or skip the transaction to restore replication.</p>
Slave must silently retry current transaction
MySQL raises error 1806 with message "Slave must silently retry current transaction" when a replication worker thread encounters a temporary lock or deadlock that should resolve on a second attempt. Instead of stopping replication, the slave is instructed to retry automatically.
The error appears in the error log rather than the SQL thread output, so many administrators only notice it when replication lags or stalls. Fixing the underlying contention is essential to keep replication real-time and consistent.
Most occurrences trace back to InnoDB row-level locks held on the slave while another concurrent transaction modifies the same rows. The worker thread backs off and retries instead of aborting.
Configuration mismatches such as low innodb_lock_wait_timeout or aggressive parallel replication settings can increase the likelihood of collisions that trigger silent retries.
First confirm that the slave thread is indeed in a retry loop by checking SHOW PROCESSLIST and the relay log positions. If retries continue to fail, intervene manually.
Increase lock wait timeout values, isolate long-running updates, or temporarily stop application writes that conflict with replicated statements. When safe, restart the slave SQL thread or skip the problematic transaction.
High-volume OLTP workloads often hit this error when parallel replication workers contend for hot rows. Reducing slave_parallel_workers or switching to logical row-based replication can help.
Schema changes executed on the primary may lock large tables. Run DDL during low-traffic windows or use pt-osc to minimize lock times and prevent retries on the replica.
Keep transactions short and commit frequently to release locks quickly on the primary and replica. Align innodb_lock_wait_timeout across servers to consistent values.
Enable replica_parallel_workers conservatively and monitor EXECUTION_LAG. Tools like Galaxy surface lock waits in real time, letting engineers terminate blocking sessions before retries snowball.
Errors 1213 (ER_LOCK_DEADLOCK) and 1205 (ER_LOCK_WAIT_TIMEOUT) reflect similar lock conflicts but occur on the primary. Resolve with shorter transactions and proper indexing.
Error 1590 (ER_SLAVE_FATAL_ERROR) stops replication completely. Unlike 1806, it requires manual intervention such as CHANGE MASTER TO or log file position adjustments.
Concurrent updates on the same rows force the replica worker to wait, back off, and retry the transaction.
Analytical queries or bulk loads hold shared locks, delaying worker threads and triggering retries.
A short timeout causes quick conflict detection, increasing the frequency of silent retries.
Too many slave_parallel_workers competing for limited resources amplify lock collisions.
Primary server deadlock requiring transaction rollback and retry from client.
Transaction exceeded lock wait timeout on primary or replica.
Critical replication failure that halts SQL thread until manual recovery.
No. Occasional entries mean replication handled a benign lock conflict. Frequent messages signal deeper contention.
Yes, but monitor Seconds_Behind_Master. Rising lag suggests retries cannot keep up.
It reduces retry loops but may prolong lock waits. Combine with shorter transactions and tuned parallelism.
Galaxy surfaces live lock metrics, highlights blocking queries, and lets engineers kill sessions without leaving the editor, preventing cascading retries.
.avif)
.avif){kind=logo}
