Azure Database for MySQL

Azure Database for MySQL is a Platform-as-a-Service (PaaS) database service that provides a managed MySQL database engine. It is based on the MySQL Community Edition, version 5.7 or 8.0 (as of the latest updates). The service handles all infrastructure management: patching, backups, replication, and high availability. You do not have access to the underlying operating system or MySQL configuration files; instead, you configure the service through Azure portal, CLI, or REST API using server parameters.

The primary benefit is reduced administrative overhead. Traditional MySQL on a VM requires you to manage OS updates, MySQL patches, storage, backups, and replication. With Azure Database for MySQL, these are automated. You can also scale compute and storage independently, set up read replicas with minimal effort, and achieve high availability with a 99.99% SLA (when using Business Critical tier with zone-redundant deployment). The service integrates with Azure Active Directory for authentication and Azure Monitor for performance metrics.

Azure Database for MySQL runs on a managed cluster of virtual machines. Each server instance is a logical MySQL server that maps to a physical node. The service uses a storage layer based on Azure Premium Storage or Ultra Disk, depending on the tier. Write-ahead logging (WAL) ensures durability. The service automatically maintains three copies of data within the same region for redundancy (local redundant storage). For backup, it takes full daily backups, transaction log backups every 5 minutes, and differential backups every 12 hours. These are stored in geo-redundant storage if you enable that option.

Azure Database for MySQL offers two deployment models: Single Server and Flexible Server. Single Server is the original offering, now in a retirement path (scheduled for retirement in 2025). Flexible Server is the current recommended option. Key differences:

For the DP-900 exam, you should know that Flexible Server is the newer and more feature-rich option. However, both are still examinable.

You can scale compute (vCores and memory) and storage separately. Compute scaling can be done manually or via autoscale (Flexible Server only). Storage scales automatically up to a maximum of 16 TB. You cannot scale down storage. The service supports up to 10 read replicas (Flexible Server) with asynchronous replication using MySQL's native binlog replication. Replicas can be within the same region or cross-region.

Automatic backups are retained for 7 to 35 days (configurable). You can restore to any point within the retention period (point-in-time restore). Restores create a new server instance. Geo-restore is available if you enable geo-redundant storage (for Single Server) or cross-region restore (Flexible Server).

Azure Database for MySQL integrates with Azure Monitor. Key metrics include CPU percent, memory percent, storage percent, IOPS, connections, and replication lag. You can set alerts based on thresholds. Query Performance Insight provides query-level performance data.

Although you cannot modify the my.cnf file, you can change many MySQL server parameters through the Azure portal or CLI. Examples:

You can also reset parameters to default values.

# Create a resource group
az group create --name myResourceGroup --location eastus

# Create a MySQL Flexible Server
az mysql flexible-server create \
  --resource-group myResourceGroup \
  --name myMySQLServer \
  --location eastus \
  --admin-user myAdmin \
  --admin-password myPassword \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --public-access 0.0.0.0/0

# Configure firewall rule
az mysql flexible-server firewall-rule create \
  --resource-group myResourceGroup \
  --name myMySQLServer \
  --rule-name AllowMyIP \
  --start-ip-address 203.0.113.0 \
  --end-ip-address 203.0.113.255

Use the MySQL client or any application that supports MySQL protocol. The connection string includes the server name (e.g., myMySQLServer.mysql.database.azure.com), port 3306, and SSL mode required.

mysql --host myMySQLServer.mysql.database.azure.com --user myAdmin --password --ssl-mode=REQUIRED

Storage is billed per GB per month. IOPS are billed separately in some tiers.

You can create up to 10 read replicas. Replication is asynchronous. Replicas can be in the same region or cross-region. You can promote a replica to a standalone server. Replication lag is monitored.

For DP-900, you need to understand the differences between PaaS and IaaS, when to choose Azure Database for MySQL over SQL Server or PostgreSQL, the high-level features (backup, HA, scaling), and the deployment options (Single Server vs Flexible Server). You will not be asked to write CLI commands, but you should know what is possible.

An online retailer runs a MySQL-based e-commerce platform on Azure. They chose Azure Database for MySQL Flexible Server in the General Purpose tier. During Black Friday, traffic spikes require additional compute. They enable autoscale (preview) to automatically increase vCores from 4 to 16 during peak hours. The database handles thousands of transactions per second. They set up a read replica in a different Azure region for disaster recovery. Monitoring alerts on CPU > 80% trigger scaling actions. Misconfiguration could occur if the max storage is set too low (e.g., 100 GB instead of 1 TB), causing auto-growth failures. They also use VNet integration to secure traffic between the web tier and database.

A SaaS provider uses Azure Database for MySQL to serve multiple tenants. Each tenant gets a separate database on the same server. They use connection pooling to manage hundreds of connections. The Burstable tier is cost-effective for small tenants, but they upgrade to General Purpose for larger ones. They enable audit logs to track data access for compliance. A common pitfall is reaching the max_connections limit (default 100 for Burstable B1ms). They increase it via server parameters. They also use Azure Active Directory authentication to avoid storing passwords in application code.

A financial services company migrates a legacy MySQL 5.7 database to Azure. They use Azure Database Migration Service to assess compatibility and perform an online migration with minimal downtime. Post-migration, they enable geo-redundant backups for compliance. They configure a maintenance window for patching during off-hours. A challenge is that some stored procedures use MySQL features not supported in Azure (e.g., superuser privileges). They refactor the code. They also set up performance monitoring using Query Performance Insight to identify slow queries.