High severityconnection
MySQL Error:
1130
What does this error mean?
MySQL error 1130 means the server rejected the TCP connection before authentication even starts. The server looks up the client's IP address (or reverse-DNS hostname) in the `mysql.user` table and finds no matching row for the requested username + host combination. The client receives the error immediately after the TCP handshake — no password prompt, no SSL negotiation. In data-pipeline context this typically surfaces as an ADF pipeline_failed event, a dbt connection timeout, or a Power BI refresh failure with the message 'Host is not allowed to connect to this MySQL server'. The root cause is almost always a mismatch between the IP the pipeline actually connects from and the host value in the GRANT statement.
Common causes
- 1The MySQL user was created with a specific host (e.g., `'etl_user'@'10.0.1.5'`) but the client connects from a different IP — common after VM migration or infrastructure changes.
- 2Azure Data Factory's managed VNet integration runtime uses outbound IPs from a pool that rotates periodically. The IP that worked yesterday may not be the IP used today.
- 3A self-hosted integration runtime was restarted or moved to a new VM, changing its outbound IP without updating the MySQL GRANT.
- 4DNS-based host grants (e.g., `'user'@'runner.internal'`) fail because the MySQL server's `skip-name-resolve` is enabled, so it only matches by IP and never resolves hostnames.
- 5A firewall or NAT gateway between the client and MySQL rewrites the source IP to one that does not match any GRANT entry — the MySQL server sees the NAT IP, not the original client IP.
- 6After a MySQL upgrade or migration, the `mysql.user` table was not fully migrated and host-specific grants are missing from the new instance.
How to fix it
- 1Step 1: Identify the connecting IP. From the client machine run: `curl -s ifconfig.me` (public IP) or check ADF's integration runtime monitoring page for the outbound IP list.
- 2Step 2: Check existing grants on the MySQL server: `SELECT user, host FROM mysql.user WHERE user='your_user';` — verify if the IP from step 1 appears in the host column.
- 3Step 3: If no matching row exists, create a grant for the specific IP: `CREATE USER 'your_user'@'10.0.1.5' IDENTIFIED BY 'your_password'; GRANT SELECT ON your_db.* TO 'your_user'@'10.0.1.5'; FLUSH PRIVILEGES;`
- 4Step 4: For services with rotating IPs (ADF managed VNet, cloud functions), use a subnet wildcard: `CREATE USER 'your_user'@'10.0.%' IDENTIFIED BY 'your_password'; GRANT SELECT ON your_db.* TO 'your_user'@'10.0.%'; FLUSH PRIVILEGES;`
- 5Step 5: If `skip-name-resolve` is ON (check with `SHOW VARIABLES LIKE 'skip_name_resolve';`), replace any hostname-based grants with IP-based grants — hostname matching is silently disabled.
- 6Step 6: Test the connection from the actual pipeline host, not from your laptop: `mysql -h your-mysql-host -u your_user -p --protocol=tcp` — this confirms the grant works for that specific source IP.
- 7Step 7: After confirming the fix, trigger a manual pipeline run in ADF (`Debug` in pipeline editor) or refresh the Power BI dataset from Service → Settings → Datasets → Refresh now to verify end-to-end.
Example log output
ERROR 1130 (HY000): Host '10.0.4.27' is not allowed to connect to this MySQL server
Connection attempt by 'etl_user' from 10.0.4.27 rejected — no matching host in mysql.user
[2026-05-11 08:15:03] ADF pipeline 'ingest_mysql_orders' failed: MySQL connector error 1130 after 0 retries