Getting Internal error while migrating single server to flex mysql server

Varadarajan, Anandji 0 Reputation points
2024-06-10T11:21:03.08+00:00

Getting InternalServerError while running a flex server migration in poc env

az mysql flexible-server import create --data-source-type 'mysql_single' --data-source 'server' --resource-group 'poc-infra-rg'  --name 'flexserv-01' --key 'https://poc-mysql-01-key/xxxxxxx' --identity 'poc-agw-01'
Checking the existence of the resource group 'poc-infra-rg'...
Resource group 'poc-infra-rg' exists ? : True 
IOPS is 396 which is either your input or free(maximum) IOPS supported for your storage size and SKU.
Creating MySQL Server 'flexserv-01' in group 'poc-infra-rg'...
Your server 'poc-mysql-flexserv-01' is using sku 'Standard_D2ds_v4' (Paid Tier). Please refer to https://aka.ms/mysql-pricing for pricing details
(InternalServerError) An unexpected error occured while processing the request. Tracking ID: '792495a3-8af2-44eb-88bc-e0693919775a'
Code: InternalServerError
Message: An unexpected error occured while processing the request. Tracking ID: '792495a3-8af2-44eb-88bc-e0693919775a'
Azure Database for MySQL
Azure Database for MySQL
An Azure managed MySQL database service for app development and deployment.
757 questions
{count} votes

1 answer

Sort by: Most helpful
  1. ShaktiSingh-MSFT 14,281 Reputation points Microsoft Employee
    2024-06-10T14:38:28.6133333+00:00

    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

    1 person found this answer helpful.
    0 comments No comments