Skip to content

Commit b613583

Browse files
committed
[MySQL] add new section
1 parent 3bf19c7 commit b613583

File tree

1 file changed

+15
-1
lines changed

1 file changed

+15
-1
lines changed

articles/mysql/flexible-server/concepts-networking-vnet.md

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ Azure Database for MySQL flexible server integrates with Azure [Private DNS zone
3737

3838
In the above diagram,
3939

40-
1. Azure Database for MySQL flexible server instances are injected into a delegated subnet - 10.0.1.0/24 of virtual network **VNet-1**.
40+
1. Azure Databases for MySQL flexible server instances are injected into a delegated subnet - 10.0.1.0/24 of virtual network **VNet-1**.
4141
2. Applications deployed on different subnets within the same virtual network can access the Azure Database for MySQL flexible server instances directly.
4242
3. Applications deployed on a different virtual network **VNet-2** don't have direct access to Azure Database for MySQL flexible server instances. Before they can access an instance, you must perform a [private DNS zone virtual network peering](#private-dns-zone-and-virtual-network-peering).
4343

@@ -118,6 +118,20 @@ You can then use the Azure Database for MySQL flexible server servername (FQDN)
118118
- Private DNS integration config can't be changed after deployment.
119119
- Subnet size (address spaces) can't be increased after resources exist in the subnet.
120120

121+
## Move from private access (virtual network integrated) network to public access or private link
122+
123+
Azure Database for MySQL - Flexible Server can be transitioned from Private access (virtual network Integrated) to public access, with the option to use Private Link. This functionality enables servers to switch from virtual network integrated to Private Link/Public infrastructure seamlessly, without the need to alter the server name or migrate data, simplifying the process for customers.
124+
125+
> [!NOTE]
126+
> That once the transition is made, it cannot be reversed. The transition involves a downtime of approximately 5-10 minutes for Non-HA servers and about 20 minutes for HA-enabled servers.
127+
128+
The process is conducted in offline mode and consists of two steps:
129+
130+
1. Detaching the server from the virtual network infrastructure.
131+
1. Establishing a Private Link or enabling public access.
132+
133+
- For guidance on transitioning from Private access network to Public access or Private Link, refer to the provided tutorial. This resource offers step-by-step instructions to facilitate the process.
134+
121135
## Next steps
122136

123137
- Learn how to enable private access (virtual network integration) using the [Azure portal](how-to-manage-virtual-network-portal.md) or [Azure CLI](how-to-manage-virtual-network-cli.md).

0 commit comments

Comments
 (0)