Connectivity architecture in Azure Database for MariaDB
Important
Azure Database for MariaDB is on the retirement path. We strongly recommend that you migrate to Azure Database for MySQL. For more information about migrating to Azure Database for MySQL, see What's happening to Azure Database for MariaDB?.
This article explains the Azure Database for MariaDB connectivity architecture and how the traffic is directed to your Azure Database for MariaDB instance from clients both within and outside Azure.
Connectivity architecture
Connection to your Azure Database for MariaDB is established through a gateway that is responsible for routing incoming connections to the physical location of your server in our clusters. The following diagram illustrates the traffic flow.
As client connects to the database, the connection string to the server resolves to the gateway IP address. The gateway listens on the IP address on port 3306. Inside the database cluster, traffic is forwarded to appropriate Azure Database for MariaDB. Therefore, in order to connect to your server, such as from corporate networks, it's necessary to open up the client-side firewall to allow outbound traffic to be able to reach our gateways. Below you can find a complete list of the IP addresses used by our gateways per region.
Azure Database for MariaDB gateway IP addresses
The gateway service is hosted on group of stateless compute nodes sitting behind an IP address, which your client would reach first when trying to connect to an Azure Database for MariaDB server.
As part of ongoing service maintenance, we'll periodically refresh compute hardware hosting the gateways to ensure we provide the most secure and performant experience. When the gateway hardware is refreshed, a new ring of the compute nodes is built out first. This new ring serves the traffic for all the newly created Azure Database for MariaDB servers and it will have a different IP address from older gateway rings in the same region to differentiate the traffic. Once the new ring is fully functional, the older gateway hardware serving existing servers are planned for decommissioning. Before decommissioning a gateway hardware, customers running their servers and connecting to older gateway rings will be notified via email and in the Azure portal, three months in advance before decommissioning. The decommissioning of gateways can impact the connectivity to your servers if
- You hard code the gateway IP addresses in the connection string of your application. It is not recommended. You should use fully qualified domain name (FQDN) of your server in the format
<servername>.mariadb.database.chinacloudapi.cn, in the connection string for your application. - You don't update the newer gateway IP addresses in the client-side firewall to allow outbound traffic to be able to reach our new gateway rings.
Important
If customer connectivity stack needs to connect directly to gateway instead of recommended DNS name approach, or allow-list gateway in the firewall rules for connections to\from customer infrastructure, we strongly encourage customers to use Gateway IP address subnets versus hardcoding static IP in order to not be impacted by this activity in a region that may cause IP to change within the subnet range.
The following table lists the gateway IP addresses of the Azure Database for MariaDB gateway for all data regions. The most up-to-date information of the gateway IP addresses for each region is maintained in the table below. In the table below, the columns represent following:
- Gateway IP address subnets: This column lists the IP address subnets of the gateway rings located in the particular region. As we retire older gateway hardware, we recommend that you open the client-side firewall to allow outbound traffic for the IP address subnets in the region you're operating.
- Gateway IP addresses: Periodically, individual Gateway IP addresses will be retired and traffic will be migrated to corresponding Gateway IP address subnets.
We strongly encourage customers to move away from relying on any individual Gateway IP address (since these will be retired in the future). Instead allow network traffic to reach both the individual Gateway IP addresses and Gateway IP address subnets in a region.
| Region name | Current Gateway IP address | Gateway IP address subnets |
|---|---|---|
| China East | 52.130.112.139 | 52.130.112.136/29, 52.130.13.96/27 |
| China East 2 | 40.73.82.1, 52.130.120.89 | 52.130.120.88/29, 52.130.7.0/27 |
| China North | 52.130.128.89 | 52.130.128.88/29, 40.72.77.128/27 |
| China North 2 | 40.73.50.0 | 52.130.40.64/29, 52.130.21.160/27 |
Connection redirection
Azure Database for MariaDB supports another connection policy, redirection that helps to reduce network latency between client applications and MariaDB servers. With this feature, after the initial TCP session is established to the Azure Database for MariaDB server, the server returns the backend address of the node hosting the MariaDB server to the client. Thereafter, all subsequent packets flow directly to the server, bypassing the gateway. As packets flow directly to the server, latency and throughput have improved performance.
This feature is supported in Azure Database for MariaDB servers with engine versions 10.2 and 10.3.
Support for redirection is available in the PHP mysqlnd_azure extension, developed by Microsoft, and is available on PECL. See the configuring redirection article for more information on how to use redirection in your applications.
Important
Support for redirection in the PHP mysqlnd_azure extension is currently in preview.