Een dbt model met `materialized='table'` probeert de tabel te droppen en opnieuw aan te maken, maar de DROP slaagde niet in een eerdere run. De tabel bestaat nog steeds en de nieuwe CREATE TABLE knalt er tegenaan.. Een Flyway- of Liquibase-migratiescript bevat een bare CREATE TABLE zonder IF NOT EXISTS. Na een gedeeltelijk mislukte deployment staat de tabel al in de database, maar de migratietool beschouwt de versie als niet-toegepast en voert het script opnieuw uit.. In Azure Data Factory wordt een Copy Activity gevolgd door een stored procedure die de doeltabel aanmaakt. Als de pipeline opnieuw wordt getriggerd na een gedeeltelijke mislukking — bijvoorbeeld door een retry-policy of een handmatige herstart — bestaat de tabel al van de eerste run.. Parallelle Airflow DAG-runs: twee instanties van dezelfde DAG starten vrijwel gelijktijdig op en beide proberen dezelfde staging-tabel aan te maken. De tweede taak gooit 1050 omdat de eerste hem al aanmaakte.. Een CI/CD-pipeline voert migratiescripts uit op een branch-database die niet is teruggezet naar de baseline. De tabel is al aangemaakt door een vorige test-run; de migratiescripts bevatten geen idempotentie-check.. Handmatige SQL-scripts die door meerdere teamleden worden gedeeld en buiten het migratieframework om worden uitgevoerd, waardoor de schemastate afwijkt van wat het migratietool verwacht.. Een ELT-tool zoals Fivetran of Stitch maakt bij initiële sync een staging-tabel aan. Als de sync wordt hergestart zonder de bestaande data te wissen — bijvoorbeeld na een connector reset — botst de nieuwe CREATE TABLE op de bestaande tabel.

Stap 1: Controleer of de tabel bestaat en wat erin zit: `SHOW TABLES LIKE 'your_table';` en `DESCRIBE your_table;` — zo weet je of het een lege remnant is van een mislukte run of een tabel met productiedata die je niet mag droppen.. Stap 2: Als de tabel veilig verwijderd kan worden (staging/temp): `DROP TABLE IF EXISTS your_table;` en voer daarna de CREATE TABLE opnieuw uit. Controleer eerst met `SELECT COUNT(*) FROM your_table;` of de tabel leeg is.. Stap 3: Maak het CREATE TABLE-statement idempotent voor toekomstige runs: `CREATE TABLE IF NOT EXISTS your_table (id INT PRIMARY KEY, ...);` — MySQL slaat de aanmaak stilzwijgend over als de tabel al bestaat.. Stap 4: In dbt — controleer de materialization config in het model. Bij `materialized='table'` doet dbt automatisch DROP TABLE IF EXISTS gevolgd door CREATE TABLE. Als 1050 toch optreedt, controleer of een pre-hook of macro handmatig een CREATE uitvoert die conflicteert: `grep -r 'CREATE TABLE' models/`. Stap 5: Bij Flyway of Liquibase — herstel de migratiestatus handmatig: voor Flyway voer je `flyway repair` uit zodat de checksum-mismatch wordt opgelost, of markeer de versie als toegepast met `INSERT INTO flyway_schema_history (version, ...) VALUES ('V3', ...);` als de tabel inhoudelijk correct is.. Stap 6: Voorkom parallelle aanmaak bij Airflow: voeg een `ExternalTaskSensor` of `BranchPythonOperator` toe die eerst checkt of de tabel al bestaat, of gebruik een database-lock via `SELECT GET_LOCK('create_your_table', 10);` aan het begin van de taak.. Stap 7: Voeg schema-state validatie toe aan je CI/CD-pipeline: `mysql -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='yourdb' AND table_name='your_table';"` — bij returnwaarde > 0 laat de pipeline het aanmaakstap overslaan of stop de run met een duidelijke foutmelding.

Medium severityschema

MySQL Error:
1050

Impact

Als de error terugkomt na elke retry, is er waarschijnlijk een onvolledige rollback in je migratietool — de schemastate in de database wijkt af van wat het migratieframework denkt. Downstream dbt-modellen en ADF-pipelines die van deze tabel afhangen, mislukken volledig totdat de tabel-state is gesynchroniseerd, wat kan leiden tot stale rapportage-data en gemiste SLA-deadlines.

Zodra error 1050 optreedt, stopt de betreffende activiteit of dbt-model onmiddellijk. Alle downstream modellen en activiteiten die afhankelijk zijn van deze tabel worden overgeslagen of mislukken eveneens. In een ADF-pipeline met een retry-policy wordt de activiteit opnieuw geprobeerd, maar zolang de tabel bestaat gooit elke poging dezelfde fout. Bij dbt betekent dit dat het gehele build-graph vanaf het foutieve model niet wordt uitgevoerd. Dashboards en rapporten die van de tabel afhangen, tonen verouderde data totdat het probleem handmatig is opgelost.

What does this error mean?

MySQL error 1050 wordt gegooid wanneer een CREATE TABLE statement probeert een tabel aan te maken die al bestaat in het opgegeven schema. De DDL-operatie wordt volledig afgebroken — er wordt niets aangemaakt of gewijzigd. In een data-pipeline manifesteert dit zich typisch als een mislukte migratieronde of een dbt run die vastloopt in de DDL-fase. De engineer ziet een rood job-resultaat in ADF, Airflow of dbt Cloud, met in de logs de melding 'Table already exists'. De tabel zelf blijft intact, maar de downstream transformaties die op deze tabel wachten, starten niet.

Common causes

1Een dbt model met `materialized='table'` probeert de tabel te droppen en opnieuw aan te maken, maar de DROP slaagde niet in een eerdere run. De tabel bestaat nog steeds en de nieuwe CREATE TABLE knalt er tegenaan.
2Een Flyway- of Liquibase-migratiescript bevat een bare CREATE TABLE zonder IF NOT EXISTS. Na een gedeeltelijk mislukte deployment staat de tabel al in de database, maar de migratietool beschouwt de versie als niet-toegepast en voert het script opnieuw uit.
3In Azure Data Factory wordt een Copy Activity gevolgd door een stored procedure die de doeltabel aanmaakt. Als de pipeline opnieuw wordt getriggerd na een gedeeltelijke mislukking — bijvoorbeeld door een retry-policy of een handmatige herstart — bestaat de tabel al van de eerste run.
4Parallelle Airflow DAG-runs: twee instanties van dezelfde DAG starten vrijwel gelijktijdig op en beide proberen dezelfde staging-tabel aan te maken. De tweede taak gooit 1050 omdat de eerste hem al aanmaakte.
5Een CI/CD-pipeline voert migratiescripts uit op een branch-database die niet is teruggezet naar de baseline. De tabel is al aangemaakt door een vorige test-run; de migratiescripts bevatten geen idempotentie-check.
6Handmatige SQL-scripts die door meerdere teamleden worden gedeeld en buiten het migratieframework om worden uitgevoerd, waardoor de schemastate afwijkt van wat het migratietool verwacht.
7Een ELT-tool zoals Fivetran of Stitch maakt bij initiële sync een staging-tabel aan. Als de sync wordt hergestart zonder de bestaande data te wissen — bijvoorbeeld na een connector reset — botst de nieuwe CREATE TABLE op de bestaande tabel.

How to fix it

1Stap 1: Controleer of de tabel bestaat en wat erin zit: `SHOW TABLES LIKE 'your_table';` en `DESCRIBE your_table;` — zo weet je of het een lege remnant is van een mislukte run of een tabel met productiedata die je niet mag droppen.
2Stap 2: Als de tabel veilig verwijderd kan worden (staging/temp): `DROP TABLE IF EXISTS your_table;` en voer daarna de CREATE TABLE opnieuw uit. Controleer eerst met `SELECT COUNT(*) FROM your_table;` of de tabel leeg is.
3Stap 3: Maak het CREATE TABLE-statement idempotent voor toekomstige runs: `CREATE TABLE IF NOT EXISTS your_table (id INT PRIMARY KEY, ...);` — MySQL slaat de aanmaak stilzwijgend over als de tabel al bestaat.
4Stap 4: In dbt — controleer de materialization config in het model. Bij `materialized='table'` doet dbt automatisch DROP TABLE IF EXISTS gevolgd door CREATE TABLE. Als 1050 toch optreedt, controleer of een pre-hook of macro handmatig een CREATE uitvoert die conflicteert: `grep -r 'CREATE TABLE' models/`
5Stap 5: Bij Flyway of Liquibase — herstel de migratiestatus handmatig: voor Flyway voer je `flyway repair` uit zodat de checksum-mismatch wordt opgelost, of markeer de versie als toegepast met `INSERT INTO flyway_schema_history (version, ...) VALUES ('V3', ...);` als de tabel inhoudelijk correct is.
6Stap 6: Voorkom parallelle aanmaak bij Airflow: voeg een `ExternalTaskSensor` of `BranchPythonOperator` toe die eerst checkt of de tabel al bestaat, of gebruik een database-lock via `SELECT GET_LOCK('create_your_table', 10);` aan het begin van de taak.
7Stap 7: Voeg schema-state validatie toe aan je CI/CD-pipeline: `mysql -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='yourdb' AND table_name='your_table';"` — bij returnwaarde > 0 laat de pipeline het aanmaakstap overslaan of stop de run met een duidelijke foutmelding.

Example log output

ERROR 1050 (42S01): Table 'staging_orders' already exists
[dbt] Database Error in model stg_orders (models/staging/stg_orders.sql): Table 'analytics.staging_orders' already exists
[ADF] Activity 'CreateStagingTable' failed: MySqlException: Table 'staging_orders' already exists (errno 1050)

Frequently asked questions

Hoe fix ik MySQL error 1050 in een dbt run?

Controleer eerst of een pre-hook of macro in je dbt-project handmatig een CREATE TABLE uitvoert — dat conflicteert met de ingebouwde materialization-logica. Bij `materialized='table'` handelt dbt de DROP en CREATE zelf af. Als de error toch optreedt, kijk dan in dbt Cloud of de terminal naar de volledige stacktrace: vaak is er een eerdere run half afgebroken en is de tabel in een inconsistente staat. Drop de tabel handmatig en start de dbt run opnieuw.

Kan ik MySQL 1050 oplossen zonder de tabel te droppen?

Ja — vervang je CREATE TABLE door CREATE TABLE IF NOT EXISTS. MySQL slaat de aanmaak dan over als de tabel al bestaat en de query slaagt zonder fout. Let op: de tabelstructuur wordt dan niet bijgewerkt als het schema is gewijzigd. Gebruik in dat geval ALTER TABLE om kolommen toe te voegen of RENAME TABLE als je van een oude naar een nieuwe definitie migreert.

Waarom gooit mijn Flyway-migratie steeds 1050 na een retry?

Flyway markeert een versie als mislukt in de flyway_schema_history tabel als een script halverwege stopt. Bij de volgende run probeert Flyway datzelfde script opnieuw, inclusief de CREATE TABLE die de eerste keer al deels is uitgevoerd. Voer `flyway repair` uit om de mislukte entry te verwijderen, of maak het script idempotent met IF NOT EXISTS. Controleer daarna met `SELECT * FROM flyway_schema_history ORDER BY installed_on DESC LIMIT 5;` of de versie correct geregistreerd staat.

Hoe voorkom ik MySQL 1050 bij parallelle pipeline-runs?

Gebruik een application-level lock: `SELECT GET_LOCK('init_tablename', 30);` aan het begin van de taak en `SELECT RELEASE_LOCK('init_tablename');` aan het einde. Zo wacht een parallelle instantie tot de eerste klaar is. In Airflow kun je ook een `max_active_runs=1` instellen op de DAG om gelijktijdige uitvoering volledig te voorkomen.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html