Lakeflow Connect MySQL connector connects to wrong host IP (e.g. 172.24.215.0 instead of configured 172.24.215.11)

Hi @Max Ma , Hope you are doing well.

Thanks for the detail. Before treating this as connector behaviour, there's one very common misreading worth ruling out first, because it would fully explain what you're seeing.

1. Which address is actually in the error?

If the message is of the form Access denied for user 'lakeflow_connect_user'@'172.24.215.0', then 172.24.215.0 is not the address the connector dialed — it is the source address your MySQL server sees the connection arriving from. MySQL always reports the client host in that error, never the destination. This exact confusion is well documented: a user connecting to 172.17.0.2 received Access denied for user 'user'@'172.17.0.1' and assumed the client was targeting the wrong IP, when in fact the connection was arriving correctly and the account simply wasn't permitted from that source host

If that's your case, the connector is behaving correctly and the fix is on the grant side

-- Check which hosts the user is permitted from
SELECT User, Host FROM mysql.user WHERE User = 'lakeflow_connect_user';

-- Permit the user from the observed source (or '%')
CREATE USER 'lakeflow_connect_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'lakeflow_connect_user'@'%';
GRANT SELECT ON your_database.* TO 'lakeflow_connect_user'@'%';
FLUSH PRIVILEGES;

Could you paste the exact error string (redacted)? The 'user'@'address' shape versus a Can't connect to MySQL server shape tells us immediately which problem this is.

2. On the "last octet changed to 0" premise

172.24.215.0 isn't necessarily a rewritten address. It's a valid host address in any prefix shorter than /24 (for example 172.24.212.0/22), and it's also a typical SNAT/NAT egress address. So a .0 ending on its own isn't evidence of modification. There's no documented connector behaviour that alters a configured address, and the connector uses the host value as configured.

3. If it is genuinely a connection failure rather than an auth failure

For Can't connect to MySQL server / Connection refused, the documented causes are

• Network connectivity — verify firewall rules allow traffic from Azure Databricks IP ranges on port 3306, and check NSGs (Azure) / security groups (AWS) / firewall rules (GCP), plus VNet peering or private connectivity.
• MySQL not listening on the expected interface — check the bind-address setting; MySQL must be listening on 0.0.0.0 or on the specific IP you're connecting to. (Worth checking explicitly if this is MariaDB, which commonly ships bound to loopback.)
• Wrong host or port — confirm the saved connection value and that port 3306 is correct.

4. If the failure is only the Test Connection button in the UI

That's a known limitation, not your configuration: "The Test Connection button fails in the UI, even though credentials are correct" for MySQL users with the sha256_password or caching_sha2_password authentication plugins. The documented guidance is that you can safely ignore that error and proceed with creating the connection, and confirm your credentials independently with

mysql -h your-mysql-host -u lakeflow_connect_user -p

If the CLI connects, ingestion will work despite the Test Connection failure.

5. Please also confirm the deployment type and version

Supported sources are Azure Database for MySQL Flexible Server 5.7.44 and later, Amazon RDS 5.7.44 and later, Amazon Aurora 5.7.mysql_aurora.2.12.2 and later, MySQL on EC2 5.7.44 and later, and GCP Cloud SQL 5.7.44 and later. Your question mentions MariaDB — MariaDB is not on the supported source list, which would be worth establishing before we go further.

Reference:

Troubleshoot MySQL ingestion issues - Azure Databricks | Microsoft Learn Configure MySQL for ingestion into Azure

Hope this clarifies your queries. Please let us know if you have any further queries.
Microsoft Support Team.