MySQL Flexible Server

This page describes how MySQL Flexible Server maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of MySQL Flexible Server with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

RDS MySQL

An Azure flexible server becomes an RDS MySQL instance, with zone-redundant high availability mapped to Multi-AZ. Your application continues using the MySQL protocol.

​

Management and database connections

The adapter handles the Azure server-management calls and applies the requested target database configuration. SQL connections use the target database engine. Review both paths: accepting a server update does not make a setting active, and a running server does not establish that the application can authenticate or load its extensions.

​

Data and failover

Transfer the database contents separately, using compatible engine versions. Include users, grants, extensions, and scheduled jobs in the cutover. Update connection configuration and test reconnection after failover. The source backup history does not become a set of target restore points.

​

Compatibility differences

If RDS does not support a source parameter, the build shows the settings it will apply and requires your acknowledgement. Microsoft Entra authentication is rejected because RDS does not accept its tokens; a password is not substituted.

​

On Google Cloud

​

Cloud SQL for MySQL

A flexible server becomes a Cloud SQL for MySQL instance. Zone-redundant high availability maps to a regional instance, and server parameters become database flags. Your application keeps the MySQL protocol.

​

Management and database connections

The adapter handles the Azure server-management calls and applies the requested target database configuration. SQL connections use the target database engine. Review both paths: accepting a server update does not make a setting active, and a running server does not establish that the application can authenticate or load its extensions.

​

Data and failover

Transfer the database contents separately, using compatible engine versions. Include users, grants, extensions, and scheduled jobs in the cutover. Update connection configuration and test reconnection after failover. The source backup history does not become a set of target restore points.

​

Compatibility differences

The build identifies parameters the target does not support. It rejects Microsoft Entra authentication because the target cannot accept those tokens.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.