Database for MySQL
Azure Database for MySQL is managed MySQL on the Flexible Server model — the same managed-platform story as the PostgreSQL service, for the MySQL engine. It is the path for LAMP-stack applications, WordPress, and other open-source software that expects MySQL without running it yourself.
As with PostgreSQL, Flexible Server replaced the older Single Server model and is the only correct choice for new work. The decisions are the compute tier, whether to enable zone-redundant high availability, and how to use read replicas for scale.
Flexible Server
Flexible Server gives configurable server parameters, a chosen maintenance window, private networking, and stop/start for non-production servers. It is where Microsoft is investing, and the default for every new MySQL workload. The retired Single Server model should only appear in migration plans, not new designs.
Compute Tiers
The same three-tier shape applies: Burstable for low-traffic and dev servers that bank CPU credits, General Purpose for balanced production workloads, and Business Critical (Memory Optimized) for memory-intensive, latency-sensitive work. The tier sets the performance ceiling, so match it to the actual bottleneck.
High Availability
Zone-redundant HA runs a standby in a second availability zone with automatic failover; same-zone HA keeps the standby local for lower latency without datacenter-failure protection. HA is opt-in and billed for the standby — production workloads that cannot tolerate a zone outage should enable the zone-redundant option.
Read Replicas and Maintenance
Read replicas offload reads to asynchronous copies, including cross-region for read-scale and disaster recovery, with writes confined to the primary. A configurable maintenance window lets you control when Azure applies patching, so updates land in a low-traffic period rather than mid-peak.
- Provisioning the retired Single Server model for new work instead of Flexible Server.
- Running production without zone-redundant HA where a datacenter outage would be unacceptable.
- Leaving dev and staging servers running continuously instead of stopping them when idle.
- Choosing General Purpose for a memory-bound workload that needed the Business Critical tier.
- Directing writes at a read replica — replicas are read-only; writes belong on the primary.
- Accepting the default maintenance window instead of setting one in a low-traffic period.
- Use Flexible Server for all new MySQL deployments and migrate any remaining Single Servers.
- Enable zone-redundant HA for production workloads that cannot tolerate a datacenter failure.
- Stop non-production servers when idle to avoid paying for unused compute.
- Match the compute tier to the workload — Burstable for dev, Business Critical for memory-bound production.
- Use cross-region read replicas for read-scale and disaster recovery, keeping writes on the primary.
- Set a maintenance window in a low-traffic period so patching does not land during peak.
Knowledge Check
Which deployment model should a new Azure Database for MySQL workload use?
- Flexible Server — the current model with HA, maintenance windows, and stop/start
- Single Server — the long-term supported model with built-in HA and stop/start
- A MySQL container running on Azure Container Instances with attached storage
- Cosmos DB with the MySQL API for relational tables
What is the trade-off of same-zone HA versus zone-redundant HA?
- Lower replication latency, but no protection against a full datacenter failure
- Higher hourly cost, but the standby can also serve client writes concurrently alongside the primary
- It removes the need for read replicas by serving reads from the standby
- It bills per request instead of per hour for the standby
Where do writes go in a MySQL Flexible Server with read replicas?
- Only to the primary; replicas are read-only asynchronous copies
- To whichever read replica happens to be closest to the client
- To all replicas simultaneously for synchronous durability
- To the standby HA instance for load balancing
You got correct