Een ADF copy activity schrijft naar een MySQL-tabel terwijl een applicatietransactie (bijv. een webserver-request dat nooit werd gecommit) dezelfde rijen lockt. De copy activity wacht tot de timeout verstrijkt en gooit error 1205.. Een grote UPDATE of DELETE zonder batching lockt duizenden rijen in één transactie. Andere transacties die ook naar die tabel schrijven of lezen (afhankelijk van isolation level) blokkeren totdat de bulk-operatie klaar is.. Ontbrekende index op de WHERE-kolom van een UPDATE of DELETE dwingt MySQL tot een full table scan waarbij InnoDB preventief locks plaatst op alle gescande rijen, ook rijen die uiteindelijk niet worden gewijzigd.. Een connection pool in de applicatie heeft een 'idle open transaction' — een connectie die een BEGIN heeft gedaan maar nooit COMMIT of ROLLBACK uitvoert. Deze transactie houdt locks vast totdat de connectie wordt verbroken of de pool wordt gereset.. Twee ADF pipelines die parallel draaien en beide naar dezelfde staging-tabel schrijven (bijv. een truncate-and-load patroon) kunnen deadlock-achtige situaties veroorzaken waarbij beide op elkaars locks wachten; degene die het eerst de timeout bereikt krijgt error 1205.. dbt-modellen die incremental runs uitvoeren met een `merge` of `insert overwrite` strategie op grote partities houden row-locks vast voor de volledige duur van de SQL-statement, wat bij trage queries al snel de 50-seconden drempel overschrijdt.. MySQL replicatie-lag op een read replica gecombineerd met een applicatie die schrijft op de primary en direct leest van de replica kan leiden tot situaties waarbij de applicatie 'verouderde' locks waarneemt en onnodig lang wacht.

Stap 1 — Vind de blokkerende transactie: voer op de MySQL-server uit: `SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query, trx_rows_locked FROM information_schema.innodb_trx ORDER BY trx_started ASC;` — de oudste transactie bovenaan is vaak de blokkerende partij.. Stap 2 — Identificeer de lock-keten: `SELECT r.trx_id waiting_id, r.trx_query waiting_query, b.trx_id blocking_id, b.trx_query blocking_query, b.trx_mysql_thread_id blocking_thread FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON w.blocking_trx_id = b.trx_id JOIN information_schema.innodb_trx r ON w.requesting_trx_id = r.trx_id;` — dit toont exact welke query blokkeert.. Stap 3 — Kill de blokkerende thread als dat veilig is: `KILL ;` — dit gooit een error in de blokkerende sessie en forceert rollback van die transactie zodat de wachtende operatie verder kan.. Stap 4 — Vergroot de timeout tijdelijk voor batch-werklasten: `SET GLOBAL innodb_lock_wait_timeout = 120;` voor OLAP-pipelines. Zet dit terug naar 50 voor OLTP-omgevingen. In my.cnf permanent maken: `innodb_lock_wait_timeout = 120` onder `[mysqld]`.. Stap 5 — Splits grote DML-operaties in batches: gebruik een loop die 1.000–10.000 rijen per transactie verwerkt. Voorbeeld: `DELETE FROM events WHERE created_at < '2024-01-01' LIMIT 5000;` herhalen totdat `ROW_COUNT() = 0`. Dit houdt de lock-duur per transactie kort.. Stap 6 — Voeg ontbrekende indexes toe op WHERE-kolommen van UPDATE/DELETE: voer `EXPLAIN UPDATE mytable SET status='done' WHERE external_id = 123;` uit — als type `ALL` staat, ontbreekt een index op `external_id`. Voeg toe: `ALTER TABLE mytable ADD INDEX idx_external_id (external_id);`. Stap 7 — Configureer retry-logica in ADF: open de Copy Activity → Settings → zet 'Retry' op 3 en 'Retry interval' op 120 seconden. Voor dbt: voeg `on-run-end` hooks toe of gebruik de `--fail-fast` flag zodat een vergrendelde run niet downstream modellen blokkeert.

High severityresource

MySQL Error:
1205, Try Restarting Transaction

Q: Hoe los ik 'lock wait timeout exceeded try restarting transaction' permanent op?

De structurele oplossing is het verkorten van lock-duur: splits grote DML in batches, voeg indexes toe op WHERE-kolommen, en zorg dat applicatietransacties altijd expliciet worden gecommit of teruggedraaid. Het verhogen van `innodb_lock_wait_timeout` is een pleister, geen fix.

Q: Kan ik MySQL error 1205 automatisch laten retrien in ADF?

Ja — open de Copy Activity in ADF → tab Settings → stel Retry in op 3 en Retry interval op 60-120 seconden. Zorg dat de copy activity idempotent is (truncate-and-load of upsert op primary key) zodat een herstart geen duplicaten introduceert.

Q: Wat is het verschil tussen error 1205 en error 1213 (deadlock) in MySQL?

Error 1205 treedt op als één transactie te lang wacht op een lock — MySQL doet niets automatisch. Error 1213 is een door MySQL gedetecteerde deadlock waarbij MySQL zelf de 'goedkoopste' transactie kiest om te killen. Bij 1205 moet je zelf ingrijpen; bij 1213 handelt MySQL automatisch.

Q: Welke isolation level vermindert lock contention het meest in MySQL?

Schakel over van REPEATABLE READ (standaard) naar READ COMMITTED: `SET GLOBAL transaction_isolation = 'READ-COMMITTED';`. Bij READ COMMITTED plaatst InnoDB geen gap-locks en geeft locks vrij zodra een rij niet matched — dit vermindert contention significant bij SELECT-zware pipelines naast schrijvende applicaties. Vereis wel dat binlog_format op ROW staat voor replicatie.

Impact

Wanneer error 1205 structureel optreedt tijdens piek-uren raken ADF copy activities in een retry-storm, worden downstream dbt-modellen niet vernieuwd, en lopen Power BI-rapporten achter op de verwachte datumgrens — SLA-breuk is dan een reëel risico als de pipeline geen geautomatiseerde retry heeft.

Wanneer error 1205 optreedt wordt de volledige transactie teruggedraaid — geen gedeeltelijke schrijfoperatie. ADF markeert de activity als Failed en triggert retry indien geconfigureerd. Zonder retry mislukt de volledige pipeline-run, waardoor downstream dbt-modellen verouderde brondata verwerken of helemaal niet draaien. Bij incrementele loads kan dit betekenen dat een tijdvenster volledig wordt overgeslagen, wat leidt tot gaten in tijdreeksdata en stale aggregaties in Power BI-rapporten.

What does this error mean?

MySQL error 1205 wordt gegooid wanneer een transactie langer dan `innodb_lock_wait_timeout` seconden (standaard 50s) wacht op een row-lock die door een andere transactie wordt vastgehouden. In een data-pipeline-context betekent dit dat een ADF copy activity, dbt-model of Spark-job een rij of pagina probeert te schrijven die geblokkeerd wordt door een open applicatietransactie of een andere pipelinejob. De engineer ziet de fout als een mislukte pipeline-run met de melding 'Lock wait timeout exceeded; try restarting transaction' in de ADF activity output of dbt logs — de transactie wordt volledig teruggedraaid, niet alleen de wachtende operatie.

Common causes

1Een ADF copy activity schrijft naar een MySQL-tabel terwijl een applicatietransactie (bijv. een webserver-request dat nooit werd gecommit) dezelfde rijen lockt. De copy activity wacht tot de timeout verstrijkt en gooit error 1205.
2Een grote UPDATE of DELETE zonder batching lockt duizenden rijen in één transactie. Andere transacties die ook naar die tabel schrijven of lezen (afhankelijk van isolation level) blokkeren totdat de bulk-operatie klaar is.
3Ontbrekende index op de WHERE-kolom van een UPDATE of DELETE dwingt MySQL tot een full table scan waarbij InnoDB preventief locks plaatst op alle gescande rijen, ook rijen die uiteindelijk niet worden gewijzigd.
4Een connection pool in de applicatie heeft een 'idle open transaction' — een connectie die een BEGIN heeft gedaan maar nooit COMMIT of ROLLBACK uitvoert. Deze transactie houdt locks vast totdat de connectie wordt verbroken of de pool wordt gereset.
5Twee ADF pipelines die parallel draaien en beide naar dezelfde staging-tabel schrijven (bijv. een truncate-and-load patroon) kunnen deadlock-achtige situaties veroorzaken waarbij beide op elkaars locks wachten; degene die het eerst de timeout bereikt krijgt error 1205.
6dbt-modellen die incremental runs uitvoeren met een `merge` of `insert overwrite` strategie op grote partities houden row-locks vast voor de volledige duur van de SQL-statement, wat bij trage queries al snel de 50-seconden drempel overschrijdt.
7MySQL replicatie-lag op een read replica gecombineerd met een applicatie die schrijft op de primary en direct leest van de replica kan leiden tot situaties waarbij de applicatie 'verouderde' locks waarneemt en onnodig lang wacht.

How to fix it

1Stap 1 — Vind de blokkerende transactie: voer op de MySQL-server uit: `SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query, trx_rows_locked FROM information_schema.innodb_trx ORDER BY trx_started ASC;` — de oudste transactie bovenaan is vaak de blokkerende partij.
2Stap 2 — Identificeer de lock-keten: `SELECT r.trx_id waiting_id, r.trx_query waiting_query, b.trx_id blocking_id, b.trx_query blocking_query, b.trx_mysql_thread_id blocking_thread FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON w.blocking_trx_id = b.trx_id JOIN information_schema.innodb_trx r ON w.requesting_trx_id = r.trx_id;` — dit toont exact welke query blokkeert.
3Stap 3 — Kill de blokkerende thread als dat veilig is: `KILL <blocking_thread_id>;` — dit gooit een error in de blokkerende sessie en forceert rollback van die transactie zodat de wachtende operatie verder kan.
4Stap 4 — Vergroot de timeout tijdelijk voor batch-werklasten: `SET GLOBAL innodb_lock_wait_timeout = 120;` voor OLAP-pipelines. Zet dit terug naar 50 voor OLTP-omgevingen. In my.cnf permanent maken: `innodb_lock_wait_timeout = 120` onder `[mysqld]`.
5Stap 5 — Splits grote DML-operaties in batches: gebruik een loop die 1.000–10.000 rijen per transactie verwerkt. Voorbeeld: `DELETE FROM events WHERE created_at < '2024-01-01' LIMIT 5000;` herhalen totdat `ROW_COUNT() = 0`. Dit houdt de lock-duur per transactie kort.
6Stap 6 — Voeg ontbrekende indexes toe op WHERE-kolommen van UPDATE/DELETE: voer `EXPLAIN UPDATE mytable SET status='done' WHERE external_id = 123;` uit — als type `ALL` staat, ontbreekt een index op `external_id`. Voeg toe: `ALTER TABLE mytable ADD INDEX idx_external_id (external_id);`
7Stap 7 — Configureer retry-logica in ADF: open de Copy Activity → Settings → zet 'Retry' op 3 en 'Retry interval' op 120 seconden. Voor dbt: voeg `on-run-end` hooks toe of gebruik de `--fail-fast` flag zodat een vergrendelde run niet downstream modellen blokkeert.

Example log output

ErrorCode=UserErrorDatabaseQueryFailed,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Error happened when reading data from the database. SQL statement: SELECT ...,Source=.Net SqlClient Data Provider,''Type=MySql.Data.MySqlClient.MySqlException,Message=Lock wait timeout exceeded; try restarting transaction,Number=1205

Frequently asked questions

Hoe los ik 'lock wait timeout exceeded try restarting transaction' permanent op?

De structurele oplossing is het verkorten van lock-duur: splits grote DML in batches, voeg indexes toe op WHERE-kolommen, en zorg dat applicatietransacties altijd expliciet worden gecommit of teruggedraaid. Het verhogen van `innodb_lock_wait_timeout` is een pleister, geen fix.

Kan ik MySQL error 1205 automatisch laten retrien in ADF?

Ja — open de Copy Activity in ADF → tab Settings → stel Retry in op 3 en Retry interval op 60-120 seconden. Zorg dat de copy activity idempotent is (truncate-and-load of upsert op primary key) zodat een herstart geen duplicaten introduceert.

Wat is het verschil tussen error 1205 en error 1213 (deadlock) in MySQL?