The user was created with `CREATE USER` but no `GRANT ... ON database.*` was ever issued — only global or table-level grants exist. The GRANT statement targeted a different database name due to a typo, casing mismatch, or schema-name drift between environments (e.g. `analytics_prod` vs `analytics-prod`). The database was dropped and recreated (or restored from backup) which invalidated the original GRANT — MySQL stores grants by database name, not by internal ID. The user connects from a host that matches a more restrictive grant entry (e.g. `'user'@'10.0.0.%'` has grants, but the pipeline connects from `10.1.0.5` and falls back to `'user'@'%'` which has no database-level privileges). An IaC or provisioning script (Terraform, Ansible, Helm) created the user but the GRANT step was skipped, failed silently, or ran against the wrong MySQL instance. A DBA revoked privileges during a security audit or credential rotation and forgot to re-grant the required database-level access for service accounts

Step 1: Identify the exact user+host pair your pipeline uses. Check the ADF linked service, dbt `profiles.yml`, or Power BI gateway connection string for the username and source IP.. Step 2: Connect to MySQL as an admin and inspect current grants: `SHOW GRANTS FOR 'etl_user'@'%';` — look for a line containing `GRANT ... ON your_db.*`. If it only shows `GRANT USAGE ON *.*`, the user has zero database-level privileges.. Step 3: Verify the database name matches exactly: `SHOW DATABASES LIKE 'your_db';` — MySQL database names are case-sensitive on Linux. A grant on `Analytics` does not cover `analytics`.. Step 4: Grant the minimum required privileges. For a read-only ETL source: `GRANT SELECT, SHOW VIEW ON your_db.* TO 'etl_user'@'%';` For dbt (needs DDL): `GRANT SELECT, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, REFERENCES ON your_db.* TO 'dbt_user'@'%';`. Step 5: Apply the changes: `FLUSH PRIVILEGES;` — required if you modified the grant tables directly, good practice after any GRANT statement.. Step 6: Test from the pipeline's network path, not from localhost: `mysql -u etl_user -h 10.0.0.5 -p -e "USE your_db; SELECT 1;"` — confirms both the grant and the host match work.. Step 7: Re-trigger the failed pipeline run. In ADF: re-run the failed activity from the Monitor tab. In dbt: `dbt retry`. In Power BI: trigger a manual dataset refresh from the service.

High severityauthentication

MySQL Error:
1044

Impact

Every pipeline activity targeting this database fails immediately — ADF copy activities error out, dbt models that depend on the source are skipped, and Power BI datasets serve stale data. If your SLA depends on this MySQL source, the clock is ticking from the first failed run.

Error 1044 causes an immediate hard failure at the source — zero rows are extracted. In ADF, the copy activity fails and downstream activities in the same pipeline are skipped. In dbt, every model that references the affected source is blocked, cascading through the DAG. Power BI datasets that refresh from this MySQL source show a refresh error and continue serving stale data. Retries do not help because the error is a privilege gap, not a transient issue. Any SLA tied to this data source is breached until the GRANT is applied.

What does this error mean?

MySQL error 1044 fires after a successful login when the authenticated user tries to USE, SELECT from, or write to a database where no matching GRANT exists. The server returns `ERROR 1044 (42000): Access denied for user 'x'@'host' to database 'y'`. In a data-pipeline context this typically surfaces as a failed ADF copy activity, a dbt `run` or `source freshness` error, or a Power BI refresh timeout. The confusing part: the connection itself succeeds (no 1045), so the first instinct is to blame the query — but the root cause is a missing database-level privilege. Check `SHOW GRANTS` for the exact user+host pair your pipeline uses.

Common causes

1The user was created with `CREATE USER` but no `GRANT ... ON database.*` was ever issued — only global or table-level grants exist
2The GRANT statement targeted a different database name due to a typo, casing mismatch, or schema-name drift between environments (e.g. `analytics_prod` vs `analytics-prod`)
3The database was dropped and recreated (or restored from backup) which invalidated the original GRANT — MySQL stores grants by database name, not by internal ID
4The user connects from a host that matches a more restrictive grant entry (e.g. `'user'@'10.0.0.%'` has grants, but the pipeline connects from `10.1.0.5` and falls back to `'user'@'%'` which has no database-level privileges)
5An IaC or provisioning script (Terraform, Ansible, Helm) created the user but the GRANT step was skipped, failed silently, or ran against the wrong MySQL instance
6A DBA revoked privileges during a security audit or credential rotation and forgot to re-grant the required database-level access for service accounts

How to fix it

1Step 1: Identify the exact user+host pair your pipeline uses. Check the ADF linked service, dbt `profiles.yml`, or Power BI gateway connection string for the username and source IP.
2Step 2: Connect to MySQL as an admin and inspect current grants: `SHOW GRANTS FOR 'etl_user'@'%';` — look for a line containing `GRANT ... ON your_db.*`. If it only shows `GRANT USAGE ON *.*`, the user has zero database-level privileges.
3Step 3: Verify the database name matches exactly: `SHOW DATABASES LIKE 'your_db';` — MySQL database names are case-sensitive on Linux. A grant on `Analytics` does not cover `analytics`.
4Step 4: Grant the minimum required privileges. For a read-only ETL source: `GRANT SELECT, SHOW VIEW ON your_db.* TO 'etl_user'@'%';` For dbt (needs DDL): `GRANT SELECT, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, REFERENCES ON your_db.* TO 'dbt_user'@'%';`
5Step 5: Apply the changes: `FLUSH PRIVILEGES;` — required if you modified the grant tables directly, good practice after any GRANT statement.
6Step 6: Test from the pipeline's network path, not from localhost: `mysql -u etl_user -h 10.0.0.5 -p -e "USE your_db; SELECT 1;"` — confirms both the grant and the host match work.
7Step 7: Re-trigger the failed pipeline run. In ADF: re-run the failed activity from the Monitor tab. In dbt: `dbt retry`. In Power BI: trigger a manual dataset refresh from the service.

Example log output

ERROR 1044 (42000): Access denied for user 'etl_user'@'10.0.0.5' to database 'analytics_prod'
2026-05-11 06:15:03 [ERROR] ADF activity 'Copy_MySQL_Orders' failed: ErrorCode=UserErrorDatabaseAccessDenied, Message='Access denied for user etl_user to database analytics_prod'
2026-05-11 06:15:04 [WARN] dbt source freshness check failed for source.mysql_analytics: mysql.connector.errors.ProgrammingError: 1044 (42000): Access denied for user 'dbt_runner'@'%' to database 'analytics_prod'

Frequently asked questions

What is the difference between MySQL error 1044 and 1045?

Error 1045 means the login itself failed — wrong password, unknown user, or host mismatch. Error 1044 means the login succeeded but the user has no privileges on the specific database it tried to access. If you see 1044, your credentials are correct; the problem is a missing GRANT at the database level.

How do I give a dbt service account the minimum required privileges?

Run `GRANT SELECT, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, REFERENCES ON your_db.* TO 'dbt_user'@'%'; FLUSH PRIVILEGES;`. For read-only sources that dbt only queries (not materializes into), `GRANT SELECT, SHOW VIEW ON your_db.* TO 'dbt_user'@'%';` is enough.

Will retrying the pipeline fix MySQL error 1044?

No. Error 1044 is a privilege issue, not a transient network problem. ADF retries, dbt retries, and Power BI scheduled refreshes will all produce the same error until the GRANT is applied on the MySQL server. Fix the grant first, then retry.

Can MetricSign alert me when a pipeline fails due to this error?

Yes — MetricSign captures ADF pipeline failures, extracts the MySQL error code from the activity output, and fires an alert within minutes. The incident detail includes the database name and user that triggered 1044, so your team can fix the grant before downstream consumers notice stale data.

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