Hi ,
Thanks for reaching out to Microsoft Q&A.
Below are some observations and recommendations based on how azure MySQL flexible Server currently handles SSL enablement and compute scaling:
- SSL Enablement Link in the Portal
- UI/UX Behavior: The “Enable SSL to secure connections” text in the portal can indeed be confusing because it looks like a documentation link but is actually a toggle for SSL. Unfortunately, clicking it immediately switches SSL on without a confirmation popup.
- Feedback Recommendation: Microsoft is aware that certain portal elements can be misleading. You can open a support ticket or submit product feedback (via the portal’s “Send feedback” option) requesting:
- A confirmation dialog before enabling SSL.
- A clearer label or visual indicator (e.g., a button instead of a hyperlink).
- A confirmation dialog before enabling SSL.
In the meantime, if you need to avoid this unexpected change, it’s best to explicitly check the server’s SSL settings in Server parameters (under “SSL enforcement”) to confirm its status before or after any click.
- Impact of Enabling SSL Mid-flight
- Enabling SSL can cause client applications that are not configured for SSL to break (i.e., they may not trust the server certificate or are not prepared to negotiate SSL).
- If you accidentally enable SSL, you can toggle it off again in the server’s parameters. However, any changes to a parameter like SSL might require a short reconnect or application-level adjustment.
- Scaling Up the Compute Tier with HA
- Online Scale-Up: Azure Database for MySQL - Flexible Server uses online scaling operations. Per the FAQ, the server typically does not force a restart when you increase the compute tier.
High Availability (HA) Considerations:
- If you have HA enabled, Azure generally scales the primary and secondary instances “in parallel” or “rolling” fashion in the background.
- In principle, this is designed to incur minimal (sometimes near-zero) downtime. However, some users have reported brief connectivity blips or forced reconnections as the system finishes the scale operation.
- In most cases, client applications handle this gracefully if they implement retry logic.
- Because HA is replicating data between zones or within the same zone, each node (primary or replica) must be brought up to the new compute specification.
- You may see a brief failover or a few seconds of connectivity fluctuation. Officially, it’s “online,” but production applications might still notice a short reconnection event, especially if you have strict SLA requirements or no built-in client retries.
- In principle, this is designed to incur minimal (sometimes near-zero) downtime. However, some users have reported brief connectivity blips or forced reconnections as the system finishes the scale operation.
Tip: Schedule scale-ups during off-peak hours or in a low-traffic window if absolute zero disruption is critical. Monitor logs (in azure monitor) to confirm how many seconds of failover or disconnection, if any, actually occur.
- Summary and Recommendations
- File UI Feedback: Request the Azure portal team add a confirmation or a more descriptive label for the SSL link.
- Use Server Parameters for SSL Checks: Before or after clicking any SSL-related link, verify the server parameter for SSL enforcement so you’re certain of the current state.
- Scale Compute with Caution: The “no restart required” aspect is generally true, but plan for some short transient interruption-especially with HA.
- Implement Retry Logic: Ensure your application’s connection layer can handle brief failovers or timeouts gracefully.
By following these measures, you can reduce surprises when toggling SSL or scaling the compute tier on an HA-enabled Azure MySQL Flexible Server.
Please feel free to click the 'Upvote' (Thumbs-up) button and 'Accept as Answer'. This helps the community by allowing others with similar queries to easily find the solution.