Azure Database for MySQL is a fully managed database service, based on the MySQL Community Edition, that runs in the Microsoft cloud. While the service provides features such as patching, backups, high availability, and security, there are some requirements and best practices to consider when you're using the service.
This article lists the most common connection issues that users may encounter, together with suggestions and recommended solutions for addressing those issues.
There can be multiple potential causes for this, so be sure to review the following guidance.
select user, host from mysql.user;- or -
show grant for ‘username’@’ip addr’;This will provide a list of all users that can connect so that you can verify that the host IP address for the user in question is allowed to connect. You may be able to connect by using another account from the list.
Recommended solution: Confirm that the username you're using is passed in the format listed below:
- Single Server: username@servername
- Flexible Server: username
Recommended solution: You can reset the admin password by using the Azure portal, which will recreate the user, reset the password, and restore the admin permissions. You can then log in using the server admin account and perform further operations.
- Verify the connection string and other connection settings. See How to connect applications to Azure Database for MySQL.
- If you're using a non-admin user for your database, ensure the user has the correct. See How to create non-admin users.
Start by testing the connection from the Azure Cloud shell in the portal to see if you can connect. This can also help determine whether it’s a database availability issue or an issue with your client network.
Server firewall configuration
Recommended solution: Ensure that you’re using the correct username format and password. Also verify that the server Firewall rule allows the IP address. For temporary testing purposes only, set up a firewall rule using the range 0.0.0.0 to 255.255.255.255, which opens the server to all IP addresses. If this resolves your connectivity issue, remove this rule, and create a firewall rule for an appropriately limited IP address or address range. Regardless, when your testing is complete, be sure to remove the temporary rule.
Client firewall configuration
The firewall on your client must allow connections to your database server.
For Single Server specifically, consider the following points:
For Flexible Server specifically, there are two networking options for connecting: private access (VNet integration) or public access (allowed IP addresses). If your flexible server is deployed using private access (VNet integration), the client or application connecting to your database instance should be in the same VNet as your flexible server instance. If the client or application is deployed in a different VNet, then you must enable VNet peering between the two VNets. For more information, see Private Network Access overview.
Recommended solution: Note that the Basic tier does not support VNet service endpoints. You must remove the endpoint Microsoft.Sql from the subnet attempting to connect to the Basic tier server.
With the Single Server deployment model, a gateway is used to redirect the connections to server instances. After the connection is established, the MySQL client displays the version of MySQL set in the gateway, not the actual version running on your MySQL server instance. To determine the version of your MySQL server instance, use the SELECT VERSION(); command at the MySQL prompt. For more information, see Supported MySQL server versions.
If you use Flexible Server, TLS/SSL is enabled by default and can’t be disabled. The minimum TLS version supported on the server is TLS1.2. All incoming connections with TLS 1.0 and TLS 1.1 will be denied. You cannot disable or change the TLS version.
It is highly recommended to use only the supported drivers and tools and latest client version. Note that you can’t connect to Azure Database for MySQL using SSMS.
Recommended solution: It's highly recommend connection pooling if you have not done it yet and exam your pool configuration. For more information, see the blog post Connecting efficiently to Azure Database for MySQL with ProxySQL.
Recommended solution: Determine whether you recently increased workload or made any changes to application code or the server parameters. Each of these can contribute to higher connection latency.
Recommended solution: Reset init_connect value in the Azure portal, on the Server Parameters tab, using only the supported server parameter. For more information, see the article Troubleshoot errors commonly encountered during or post migration and the blog post Azure Database for MySQL server has gone away.
Recommended solution: Check the value of the max_connnections parameter and adjust if necessary. You can find the limit for each tier in the max_connections section of the article Server parameters. For the best experience, it's recommended that you use a connection pooler such as ProxySQL to efficiently manage connections as mentioned above. If you see an unexpectedly high number of connections, check your application code and retry the configuration as well.
Important: If you have a replica server, it’s strongly recommended to use ProxySQL to load balance traffic between the primary and replica servers.
It’s possible that you may experience either connection failures or timeouts during peak hours. Please check your active connections as well as CPU/memory/IO usage percentage in the portal metrics tab. Consider upgrading your server if any resource is hitting 100%. For more information, see performance troubleshooting basics.
You can also enable slow query logs to capture queries that are candidates for performance tuning and rewrite as necessary. For more information, see Slow query logs.
Recommended solution: Consider either expiring and/or testing connection validity before using it in your application. To avoid this issue, increase the server configured values for client timeouts, or use the Connector/J connection property autoReconnect=true to avoid this problem.
Retry logic is recommended to handle transient errors. However, you may want to limit the total retry count and delay between each retry to avoid excessive retry causing further issues. For more information, see Handle transient errors and connect efficiently.
This could be because of issue in Azure infra or maintenance activities.
Hopefully, if you've been through all the guidance above, you've identified the cause of the connectivity issue. If you have any questions, please feel free to let me know.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.