Hi Varadarajan, Anandji •,
Welcome to Microsoft Q&A forum.
As I understand, you are getting Internal error while migrating single server to flex mysql server.
Could you please check resource limit for your subscription.
Also, could you please tell if you are trying for Online/Offline migration?
Check your Network settings in case of online migration:
Your VNet must be configured with access to both the source single server and the target flexible server, so be sure to:
- Create a server-level firewall rule or configure VNET service endpoints for both the source and target Azure Database for MySQL servers to allow the VNet for Azure Database Migration Service access to the source and target databases.
- Ensure that your VNet Network Security Group (NSG) rules don't block the outbound port 443 of ServiceTag for ServiceBus, Storage, and Azure Monitor. For more information about VNet NSG traffic filtering, see Filter network traffic with network security groups.
As you prepare for the migration, be sure to consider the following limitations in online method.
- When migrating non-table objects, DMS doesn't support renaming databases.
- When migrating to a target server with bin_log enabled, be sure to enable log_bin_trust_function_creators to allow for creation of routines and triggers.
- Currently, DMS doesn't support migrating the DEFINER clause for objects. All object types with definers on the source are dropped and after the migration, the default definer for all objects that support a definer clause and that are created during schema migration, will be set to the login used to run the migration.
- Currently, DMS only supports migrating a schema as part of data movement. If nothing is selected for data movement, the schema migration won't occur. Note that selecting a table for schema migration also selects it for data movement.
- Online migration support is limited to the ROW binlog format.
- Online migration now supports DDL statement replication when migrating to a v8.0 or v5.7 Azure Database for MySQL Flexible Server target server.
- Statement replication is supported for databases, tables, and schema objects (views, routines, triggers) selected for schema migration when configuring an Azure DMS migration activity. Data definition and administration statements for databases, tables, and schema objects that aren’t selected won’t be replicated. Selecting an entire server for migration will replicate statements for any tables, databases, and schema objects that are created on the source server after the initial load has completed.
- Azure DMS statement replication supports all of the Data Definition statements listed here, with the exception of the following commands: • LOGFILE GROUP statements • SERVER statements • SPATIAL REFERENCE SYSTEM statements • TABLESPACE statements
- Azure DMS statement replication supports all of the Data Administration – Account Management statements listed here, with the exception of the following commands:
- SET DEFAULT ROLE
- SET PASSWORD
- Azure DMS statement replication supports all of the Data Administration – Table Maintenance statements listed here, with the exception of the following commands:
- REPAIR TABLE
- ANALYZE TABLE
- CHECKSUM TABLE
As you prepare for the migration, be sure to consider the following limitations for offline method.
- When migrating non-table objects, DMS doesn't support renaming databases.
- When migrating to a target server with bin_log enabled, be sure to enable log_bin_trust_function_creators to allow for creation of routines and triggers.
- When migrating the schema, DMS doesn't support creating a database on the target server.
- Currently, DMS doesn't support migrating the DEFINER clause for objects. All object types with definers on the source are dropped and after the migration the default definer for tables will be set to the login used to run the migration.
- Currently, DMS only supports migrating a schema as part of data movement. If nothing is selected for data movement, the schema migration won't occur. Note that selecting a table for schema migration also selects it for data movement.
- When migrating non-table objects, DMS doesn't support renaming databases.
- When migrating to a target server with bin_log enabled, be sure to enable log_bin_trust_function_creators to allow for creation of routines and triggers.
- When migrating the schema, DMS doesn't support creating a database on the target server.
- Currently, DMS doesn't support migrating the DEFINER clause for objects. All object types with definers on the source are dropped and after the migration the default definer for tables will be set to the login used to run the migration.
- Currently, DMS only supports migrating a schema as part of data movement. If nothing is selected for data movement, the schema migration won't occur. Note that selecting a table for schema migration also selects it for data movement.
To support migrations of databases that are 1 TB+, raise a support ticket with Azure Database Migration Service to scale-up the migration agent to support your 1 TB+ database migrations.
Let us know all if all is fine at your end.
Thanks