Azure Database for MySQL flexible server: Internal server errors during provisioning — Region North Europe

Hello @DavidBurg-4664

Based on the symptoms, this looks more like a subscription/region capacity restriction for Azure Database for MySQL Flexible Server in North Europe than an issue with your MySQL 8.4 or Standard_B1ms configuration.

ProvisionNotSupportedForRegion can occur when the subscription doesn't currently have access to provision MySQL Flexible Server capacity in the selected region. Regional availability can also vary dynamically based on capacity and quota allocation.

The fact that even the SKU/capability query returns InternalServerError before provisioning strengthens this possibility; similar subscription-scoped capability failures have been reported when regional provisioning is restricted.

I would recommend:

• Verify Microsoft.DBforMySQL is registered for the subscription.
• Test another region to determine whether the problem is specific to North Europe.
• If North Europe is required, create an Azure support request under Service and subscription limits (quotas) → Azure Database for MySQL Flexible Server → Region access and request access for North Europe.

Microsoft specifically recommends a region-access support request for this class of regional restriction.

Reference: Microsoft – Resolve capacity errors for Azure Database for MySQL

Since multiple unrelated control-plane operations are failing, don't spend much time changing the password, firewall rules, storage, or MySQL version until you've ruled out the North Europe subscription/region access issue.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.

Hi David,

I agree with you in regards to error handling.

In my experience if call to Location Based Capability Set - Get REST API returns 500 InternalServerError it means the subscription is blocked from deploying to the region. Due to capacity constraints it is common for many subscriptions to be blocked from deploying MySQL Flexible server to the most popular regions (North Europe is one of the regions that is typically blocked).

You may test using REST api with below link:

https://learn.microsoft.com/en-us/rest/api/mysql/location-based-capability-set/get?view=rest-mysql-2024-12-30&tabs=HTTP

Click Try It button, sign in, select your directory, for capabilitySetName enter default , for locationName enter the region code (e.g. westus3, westus2, centralus, eastus, etc. ), scroll down and click Run button. If you get InternalServerError it means subscription is blocked for that region, if you get a list of supported editions, skus, etc., then that means region is permitted.

I first noticed this some months ago when investigating via portal. If portal shows "Subscription '<subscription>' is not allowed to provision in '<region>' you'll see the underlying REST API call returns 500 error. That's how the portal knows to display the error. Using 500 error in this way is generally not "standard" practice, but it seems to be how this api method works.

What you can do is submit a free Service and subscription limits (quotas) request via portal and select Quota type: Azure Database for MySQL Flexible server, on Additional details tab click Enter details, Quota type: Region access, select the region you need, enter vCores requested, etc. Please note your request for region access may be denied.

How to Create an Azure support request

https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#open-a-support-request-from-the-global-header

If you have trouble creating the support request please let me know and I'll post detailed, specific to MySQL Flexible instructions including screenshots.

Thanks.

-TP

The pattern you describe is not a MySQL 8.4, Standard_B1ms, or storage configuration problem. When the capability lookup itself fails, everything downstream of it fails too, so the SKU, version and firewall settings are not worth tuning yet.

Building on TP's point about the Location Based Capability Set API: rather than probing regions one at a time, scan them in a single pass so you can see the full allow-list for your subscription.

for r in northeurope westeurope uksouth swedencentral francecentral germanywestcentral; do
  n=$(az mysql flexible-server list-skus --location $r --query "length(@)" -o tsv 2>/dev/null)
  echo "$r -> ${n:-BLOCKED/ERROR}"
done

Any region returning a non-zero count is provisionable today for your subscription. A 0/empty array and a hard InternalServerError are worth distinguishing: an empty array has also been reported as a CLI-side regression where the capabilities call returns HTTP 200 with an empty body across every region, whereas a 500 is the region-block signal. If your scan returns empty everywhere including regions you have previously deployed into, run az upgrade and retest before concluding anything about entitlement. [github.com]

One detail from your description that changes the diagnosis. You mention that updating the administrative password and creating firewall rules also failed. A subscription blocked from provisioning in a region can normally still manage servers that already exist there. So please check the exact error on those two calls:

• If they return ResourceNotFound, that is expected and simply reflects that the create never succeeded not a second symptom.
• If they return InternalServerError against a server that genuinely exists, that is a different fault to the region block and should be reported separately, because it points at the resource provider rather than at region entitlement.

Grouping all four failures together as one issue is what makes this look like a platform-wide outage when it is most likely two distinct things.

Capture the correlation ID before the evidence ages out, since the CLI surfaces very little on a 500:

az mysql flexible-server create ... --debug 2>&1 | tee mysql-create.log
az monitor activity-log list --correlation-id <correlation-id> -o jsonc

The documented mitigation for InternalServerError in the CLI is exactly this inspect the activity log for the correlation ID and retry after a few minutes. [docs.azure.cn]

The actual unblock is a quota request, not a break-fix ticket. Under Service and subscription limits (quotas), choose quota type Azure DB for MySQL Flexible Server, then on Additional details select Region access (or Region access with zonal dependency if you need a specific zone), pick North Europe, and state the vCores required. This is the route Microsoft documents for the "Provisioning in the requested region isn't supported" and "region is restricted / out of capacity" family of errors. Two caveats that are easy to miss: [learn.microsoft.com] [docs.azure.cn]

• Region access grants are evaluated case by case and can be declined outright on capacity grounds, so treat it as a request, not a switch. [learn.microsoft.com]
• A grant is scoped to subscription, region and vCore count, and a zonal grant is separate. If you later scale up or enable HA in that region, you may hit the wall again with a different error such as Specified Availability Zone not supported in this region. [docs.azure.cn]

In the meantime, deploy into whichever region your scan showed as open. If North Europe is a latency or data-residency requirement rather than a preference, say so in the quota request otherwise take the nearest permitted European region now and migrate later, since region blocks on high-demand regions can persist for a long time.

Finally, worth confirming for completeness: az provider show --namespace Microsoft.DBforMySQL --query registrationState should return Registered. An unregistered provider produces MissingSubscriptionRegistration rather than a 500, so if you are seeing 500s this is almost certainly already fine but it costs nothing to rule out. [docs.azure.cn]

HTH!

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution