MySQL to Azure Database for MySQL Flexible Server Migration¶

Migrating MySQL Community or Enterprise Edition to Azure Database for MySQL Flexible Server: version compatibility, server parameter mapping, character set handling, storage configuration, IOPS tuning, and HA architecture.

Azure Database for MySQL Flexible Server runs the same MySQL Community Edition engine as your source database. For MySQL 5.7 and 8.0 workloads, migration is a same-engine move -- no schema conversion, no SQL syntax changes, no stored procedure rewriting. The primary work involves parameter mapping, networking configuration, and data movement. MySQL 5.6 and earlier must upgrade to 5.7 or 8.0 before migrating.

1. Version compatibility¶

1.1 Supported versions on Azure MySQL Flexible Server¶

1.2 MariaDB version compatibility¶

MariaDB is not natively supported on Azure MySQL Flexible Server, but MariaDB 10.x workloads can migrate to Azure MySQL Flexible Server with caveats:

1.3 Pre-migration version upgrade path¶

If your source is MySQL 5.6 or earlier, follow this upgrade path before migrating to Azure:

MySQL 5.5 -> MySQL 5.6 -> MySQL 5.7 -> MySQL 8.0 -> Azure MySQL Flexible Server 8.0/8.4

Each version upgrade should be tested in a staging environment. Key upgrade considerations:

• 5.6 to 5.7: sql_mode defaults change (STRICT_TRANS_TABLES, ONLY_FULL_GROUP_BY), PASSWORD() function removed, mysql_old_password plugin removed
• 5.7 to 8.0: utf8mb4 becomes default charset, caching_sha2_password becomes default auth plugin, query cache removed, GROUP BY implicit sorting removed
• 8.0 to 8.4: Minor behavioral changes; LTS version with extended support

2. Server parameter mapping¶

2.1 Critical parameters¶

Azure MySQL Flexible Server exposes most MySQL server parameters through the Azure portal, CLI, or API. Some parameters are not configurable because they are managed by the service.

2.2 Parameters not available on Flexible Server¶

These parameters cannot be set because the service manages them:

2.3 Exporting current parameters¶

Capture your source server's parameter configuration before migration:

-- Export all global variables
SELECT @@global.variable_name, @@global.variable_value
FROM performance_schema.global_variables
ORDER BY variable_name;

-- Or use SHOW VARIABLES
SHOW GLOBAL VARIABLES;

-- Save to file
mysql -u root -p -e "SHOW GLOBAL VARIABLES" > /tmp/mysql_variables.txt

-- Key parameters to capture and map
SHOW VARIABLES LIKE 'innodb_%';
SHOW VARIABLES LIKE 'max_%';
SHOW VARIABLES LIKE 'character%';
SHOW VARIABLES LIKE 'collation%';
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'lower_case%';
SHOW VARIABLES LIKE 'time_zone';

3. Character set and collation handling¶

3.1 Character set migration¶

3.2 Collation mapping¶

3.3 Converting character sets¶

-- Check current database character set
SELECT schema_name, default_character_set_name, default_collation_name
FROM information_schema.schemata;

-- Check table character sets
SELECT table_name, table_collation
FROM information_schema.tables
WHERE table_schema = 'your_database';

-- Check column character sets
SELECT table_name, column_name, character_set_name, collation_name
FROM information_schema.columns
WHERE table_schema = 'your_database'
  AND character_set_name IS NOT NULL;

-- Convert database
ALTER DATABASE your_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

-- Convert table
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

-- Convert specific column
ALTER TABLE your_table MODIFY column_name VARCHAR(255)
  CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

4. Storage configuration¶

4.1 Storage tier selection¶

4.2 Sizing storage from source¶

-- Get total database size
SELECT
    table_schema AS 'Database',
    ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS 'Size (GB)',
    ROUND(SUM(data_length) / 1024 / 1024 / 1024, 2) AS 'Data (GB)',
    ROUND(SUM(index_length) / 1024 / 1024 / 1024, 2) AS 'Index (GB)'
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;

-- Get IOPS baseline (requires performance_schema or OS tools)
-- On Linux, use iostat:
-- iostat -x 1 60 | grep sda
-- Capture: r/s (reads/sec) + w/s (writes/sec) = total IOPS

Sizing guideline: Provision storage at 1.5x current data size to account for growth, temporary tables, and InnoDB overhead. For IOPS, capture peak IOPS from your source server and provision accordingly.

4.3 Storage auto-grow¶

Enable storage auto-grow to prevent out-of-space failures:

# Azure CLI
az mysql flexible-server update \
  --resource-group myResourceGroup \
  --name myMySQLServer \
  --storage-auto-grow Enabled

Storage auto-grow increases storage in increments when free space falls below a threshold. Storage can only grow -- it cannot shrink. Plan initial sizing carefully to avoid paying for over-provisioned storage.

5. IOPS configuration¶

5.1 Understanding IOPS on Flexible Server¶

IOPS on Azure MySQL Flexible Server can be scaled in two ways:

1. Storage-scaled IOPS: 3 IOPS per GB of provisioned storage. A 1 TB server gets 3,000 IOPS baseline.
2. Pre-provisioned IOPS: Additional IOPS purchased independently of storage. Allows up to 80,000 IOPS regardless of storage size.

5.2 IOPS sizing from source workload¶

-- Check InnoDB I/O statistics
SHOW GLOBAL STATUS LIKE 'Innodb_data_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_data_writes';
SHOW GLOBAL STATUS LIKE 'Innodb_data_fsyncs';
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';

-- Query performance_schema for I/O wait events
SELECT event_name, count_star, sum_timer_wait/1000000000 AS total_wait_ms
FROM performance_schema.events_waits_summary_global_by_event_name
WHERE event_name LIKE 'wait/io/file/innodb/%'
ORDER BY sum_timer_wait DESC;

6. High availability architecture¶

6.1 HA options on Flexible Server¶

6.2 Mapping source HA to Azure HA¶

6.3 HA configuration¶

# Create Flexible Server with zone-redundant HA
az mysql flexible-server create \
  --resource-group myResourceGroup \
  --name myMySQLServer \
  --location eastus \
  --sku-name Standard_D4ds_v4 \
  --tier GeneralPurpose \
  --storage-size 256 \
  --high-availability ZoneRedundant \
  --zone 1 \
  --standby-zone 2 \
  --admin-user myadmin \
  --admin-password 'ComplexPassword123!'

# Add read replicas for read scale-out
az mysql flexible-server replica create \
  --resource-group myResourceGroup \
  --name myMySQLReplica \
  --source-server myMySQLServer \
  --location eastus

7. Networking configuration¶

7.1 Connectivity options¶

7.2 VNet integration setup¶

# Create Flexible Server with VNet integration
az mysql flexible-server create \
  --resource-group myResourceGroup \
  --name myMySQLServer \
  --location eastus \
  --sku-name Standard_D8ds_v4 \
  --tier GeneralPurpose \
  --storage-size 512 \
  --vnet myVNet \
  --subnet mySubnet \
  --private-dns-zone myPrivateDnsZone

7.3 DNS configuration¶

Azure MySQL Flexible Server with VNet integration uses Azure Private DNS zones. Ensure your application DNS resolution points to the private DNS zone:

• Private DNS zone format: <server-name>.private.mysql.database.azure.com
• Public endpoint format: <server-name>.mysql.database.azure.com

8. Pre-migration checklist¶

• Verify source MySQL version is 5.7 or 8.0 (upgrade if earlier)
• Confirm all tables use InnoDB (convert MyISAM, Aria, MEMORY tables)
• Capture current server parameters (SHOW GLOBAL VARIABLES)
• Document character sets and collations for all databases, tables, columns
• Inventory stored procedures, triggers, events, and views
• Identify usage of SUPER privilege and refactor
• Test with lower_case_table_names=1 if source uses case-sensitive table names
• Review application connection strings and SSL/TLS configuration
• Capture performance baselines (slow query log, IOPS, connection counts)
• Size target compute and storage based on source metrics
• Choose HA mode (no HA, same-zone, zone-redundant)
• Plan networking (public, VNet integration, Private Link)
• Configure Entra ID authentication if replacing MySQL passwords
• Schedule maintenance window for production cutover

Next: Schema Migration | Data Migration | Tutorial: DMS Online Migration

Maintainers: csa-inabox core team Last updated: 2026-04-30