Search code examples
azureazure-virtual-machineazure-virtual-networkazure-mysql-database

I can't seem to connect to my Azure Database for MySQL server from my Azure Linux VM


I have a Linux Virtual Machine (Debian 9) deployed in Azure with Service Endpoints for Sql enabled and properly added -if I navigate the portal towards the VNet and enter the Service Endpoints tab, I can clearly see the Sql Service Endpoint listed. Just FYI, the reason for the Service Endpoint is that the VM has a dynamic IP, so I can't just whitelist it in the DB resource's configuration.

On the other hand, I have an 'Azure Database for MySQL server' deployed in the same resource group, same location and whatnot, but I can't seem to connect to it.

The steps I take when I try to connect are as follow:

  • I connect to the VM through SSH.
  • In my VM I have mysql-server installed
  • I write mysql --host <fully qualified server name> --user <server admin login name>@<server name> -p
  • I get the following error: "ERROR 9002 (28000): Server is not ready for incoming connections."

I've been reading the documentation and searching in forums for a reason why this might be happening, but I simply cannot seem to make it work. I have tried changing the status of the "Allow access to Azure services" option in the Connection security tab of the DB resource, but it doesn't seem to matter.

Could anyone have any idea of how I might go about solving this??


Solution

  • You said you enabled the SQL endpoint on the virtual network, but did you add a VNET rule to the instance (Attach an existing VNET)? You can find this in Azure Database for MySQL server -> Connection Security -> VNET Rules -> Attach existing VNET.

    If you can't see your VNET listed then there is a mismatch between the regions of your SQL server and your VNET: They must be deployed to the same one. Additionally check that you have a General Purpose or Memory Optimized server, this feature is not available in Basic tier.

    If all of this is in place, try enabling Diagnostics on the SQL Server, try logging in again a few times, then view the log file and post anything strange.