Public Preview announcement - Unified migration experience in Azure DMS
We are excited to announce that Azure Database Migration Service (DMS) now supports seamless migration of your MySQL on-premises or Virtual Machine (VM) workloads to Azure Database for MySQL - Flexible Server. This new feature, now available in public preview, allows you to use physical backup files of the MySQL server for migration. By restoring your physical data files directly to your target Flexible Server, you can migrate multi-terabyte workloads quickly and effortlessly with minimal downtime ensuring a smooth and efficient transition to Azure Database for MySQL - Flexible Server, enabling you to take full advantage of the platform's capabilities. To migrate your workloads using the Physical Online Data Migration option in Azure DMS, you need to take backups of your workload on the source server using Percona Xtrabackup utility. After taking a backup, upload the backup files to Azure Blob Storage. DMS can read the uploaded backup files from Azure Blob Storage and apply them on the target flexible server for rapid movement of large workloads to MySQL flexible server. To get started, go to your DMS project and choose "[Preview] Physical Online Data Migration" for migrating your workloads from on-premises or VMs. Limitations: You must create and configure the target Flexible server prior to migrating your physical backup files. Migration for encrypted backups isn't supported. Migration cancellation during the import operation is not supported. For more information about using physical online migration with Azure DMS please follow our detailed step-by-step instructions in our documentation: https://aka.ms/dmsPhysicalImportOnlineMigration If you have any feedback or questions about the information provided above, please leave a comment below or email us at [email protected]. Thank you!Migrating from AWS RDS for MySQL to Azure Database for MySQL - Considerations and Approaches
This post covers various strategies for migrating AWS RDS for MySQL to Azure Database for MySQL, how to use them to maximize efficiency and cost savings, different migration considerations, the importance of proper planning and preparation, and potential pitfalls that can arise during the process.Migrating an Azure Database for MySQL single server (v5.6) to a flexible server (v5.7)
If you’re still hosting databases on MySQL v5.6, this post is for you! I’ll provide details about the migration strategy and a plan for moving your v5.6 instances to MySQL v5.7 and further, to our Azure Database for MySQL – Flexible Server offering, which provides more granular control and flexibility over database management functions and configuration settings.Tips and Tricks in using mysqldump and mysql restore to Azure Database for MySQL
While importing data into Azure Database for MySQL, errors may occur. This blog will walk through common issues that you may face and how to resolve it. Access denied; you need (at least one of) the SUPER privilege(s) for this operation: Error ERROR 1227 (42000) at line 101: Access denied; you need (at least one of) the SUPER privilege(s) for this operation Operation failed with exitcode 1 Issue Importing a dump file that contains definers will result in the above error. As all of us know, only super users can perform and create definers in other schemas. Azure Database for MySQL is a managed PaaS solution and SUPER privileges is restricted. Solution Either replace the definers with the name of the admin user that is running the import process or remove it. The admin user can grant privileges to create or execute procedures by running GRANT command as in the following examples: GRANT CREATE ROUTINE ON mydb.* TO 'someuser'@'somehost'; GRANT EXECUTE ON PROCEDURE mydb.myproc TO 'someuser'@'somehost'; Example: Before: DELIMITER ;; /*!50003 CREATE*/ /*!50017 DEFINER=`root`@`127.0.0.1`*/ /*!50003 …… DELIMITER ; After: DELIMITER ;; /*!50003 CREATE*/ /*!50017 DEFINER=`AdminUserName`@`ServerName`*/ /*!50003 …… DELIMITER ; importing triggers while binary logging is enabled: Error ERROR 1419 (HY000) at line 101: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) Operation failed with exitcode 1 Issue Importing a dump file that contains triggers will result in the above error if binary logging is enabled. Solution To mitigate the issue, you need to enable the parameter “log_bin_trust_function_creators” from Azure portal parameters blade. storage engine not supported: Error ERROR 1030 (HY000) at line 114: Got error 1 from storage engine Operation failed with exitcode 1 Issue You will see the above error when you use a storage engine other than InnoDB and MEMORY. Read more on support engine types here: Storage engine support Solution Before the import process make sure that you are using a supported engine type; InnoDB and MEMORY are the only supported engine types in Azure Database for MySQL. If you dumped the data from a different engine type, edit the file and replace the storage engine. For example, exchange ENGINE=MYISAM with ENGINE=InnoDB. Note: You can always dump the schema first using the command: mysqldump --no-data option, and then dump the data using option: mysqldump --no-create-info option Example : Before: CREATE TABLE `MyTable` ( `ID` bigint(20) NOT NULL AUTO_INCREMENT, `DeviceID` varchar(50) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; After: CREATE TABLE `MyTable` ( `ID` bigint(20) NOT NULL AUTO_INCREMENT, `DeviceID` varchar(50) NOT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; InnoDB storage engine row format: Error ERROR 1031 (HY000) at line 114: Table storage engine for 'mytable' doesn't have this option Operation failed with exitcode 1 Issue In Azure Database for MySQL, four row format options are supported: DYNAMIC, COMPACT and REDUNDANT, the COMPRESSED row format is supported under certain conditions. Solution We support compressed format on General Purpose or Memory Optimized. Customer needs to enable the parameter “innodb_file_per_table” from Azure portal parameters blade, and key_block_size must be 8 or greater than 8. In default, key_block_size is 8. Please visit the Performance considerations guide for best practices while migrating into Azure Database for MySQL. Thank You !
