0% found this document useful (0 votes)
143 views

Migrate MySQL Database To Azure Database For Mysql Online

The document discusses migrating a MySQL database to Azure Database for MySQL. It describes two methods for the migration: 1) an extended downtime migration using dump/restore or import/export and 2) a minimum downtime migration using Azure Database Migration Service which allows continuous syncing of data. It also outlines some challenges to consider such as schema and version compatibility, foreign keys, and data type limitations between the source and target databases.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
143 views

Migrate MySQL Database To Azure Database For Mysql Online

The document discusses migrating a MySQL database to Azure Database for MySQL. It describes two methods for the migration: 1) an extended downtime migration using dump/restore or import/export and 2) a minimum downtime migration using Azure Database Migration Service which allows continuous syncing of data. It also outlines some challenges to consider such as schema and version compatibility, foreign keys, and data type limitations between the source and target databases.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

Migrate MySQL database to Azure Database

for MySQL

Azure Database for MySQL is a relational database service in the Microsoft cloud based on
the MySQL Community Edition (available under the GPLv2 license) database engine, versions
5.6 and 5.7. Azure Database for MySQL delivers:

 Built-in high availability with no additional cost.


 Predictable performance, using inclusive pay-as-you-go pricing.
 Scale as needed within seconds.
 Secured to protect sensitive data at-rest and in-motion.
 Automatic backups and point-in-time-restore for up to 35 days.
 Enterprise-grade security and compliance.

MySQL server/On-premise  Azure Database for MySQL


Methods:
1. Extended downtime migration
 Dump & restore
 Import & export
2. Minimum downtime migration using Azure Database Migration services.

1.Extended downtime migration


A)Dump & restore:
Use database dumps when you are migrating the entire database. You can do a dump & restore
by the following ways

 Dump and restore from the command-line (using mysqldump). On the source system
create a backup file from the command-line using mysqldump.:
mysqldump --opt -u [uname] -p[pass] [dbname] > [backupfile.sql]
 Now create a database on the target Azure Database for MySQL server. Create an empty
database on the target Azure Database for MySQL server where you want to migrate the
data. Use a tool such as MySQL Workbench, Toad, or Navicat to create the database.
 Once you have created the target database, you can use the mysql command or MySQL
Workbench to restore the data into the specific newly created database from the dump
file.
mysql -h [hostname] -u [uname] -p[pass] [db_to_restore] < [backupfile.sql]

https://docs.microsoft.com/en-us/azure/mysql/concepts-migrate-dump-restore

B)Import & Export:


When you need to selectively choose a few tables to import from an existing MySQL database
into Azure MySQL Database, it's best to use the import and export technique. By doing so, you
can omit any unneeded tables from the migration to save time and resources. The ways to to
do import & export are:

Table data export and import wizards from the object browser's context menu.
You can access these wizards from the object browser's context menu by right-clicking a table.
Then choose either Table Data Export Wizard or Table Data Import Wizard.

The following example exports the table to a CSV file:

1. Right-click the table of the database to be exported.


2. Select Table Data Export Wizard. Select the columns to be exported, row offset (if any), and
count (if any).
3. On the Select data for export page, click Next. Select the file path, CSV, or JSON file type. Also
select the line separator, method of enclosing strings, and field separator.
4. On the Select output file location page, click Next.
5. On the Export data page, click Next.
Table Data Import Wizard

The following example imports the table from a CSV file:

1. Right-click the table of the database to be imported.


2. Browse to and select the CSV file to be imported, and then click Next.
3. Select the destination table (new or existing), and select or clear the Truncate table before
import check box. Click Next.
4. Select encoding and the columns to be imported, and then click Next.
5. On the Import data page, click Next. The wizard imports the data accordingly.

SQL data export and import wizards from the Navigator pane.
Connect to the source server using MySQL workbench. Then Click on the database you want to
Import/Export and click on the Administration Tab in the Navigator Panel.

Data Export:

1. Select each schema that you want to export, optionally choose specific schema objects/tables
from each schema, and generate the export. Configuration options include export to a project
folder or self-contained SQL file, dump stored routines and events, or skip table data.

Alternatively, use Export a Result Set to export a specific result set in the SQL editor to another
format, such as CSV, JSON, HTML, and XML.
2. Select the database objects to export, and configure the related options.
3. Click Refresh to load the current objects.
4. Optionally, open the Advanced Options tab to refine the export operation. For example, add
table locks, use replace instead of insert statements, and quote identifiers with backtick
characters.
5. Click Start Export to begin the export process.

Data Import

1. Choose the project folder or self-contained SQL file, choose the schema to import into, or
choose New to define a new schema.
2. Click Start Import to begin the import process.

https://docs.microsoft.com/en-us/azure/mysql/concepts-migrate-import-export

2.Minimal downtime migration using Azure DMS


Azure DMS performs an initial load of your on-premises to Azure Database for MySQL, and then
continuously syncs any new transactions to Azure while the application remains running. After the data
catches up on the target Azure side, you stop the application for a brief moment (minimum downtime),
wait for the last batch of data (from the time you stop the application until the application is effectively
unavailable to take any new traffic) to catch up in the target, and then update your connection string to
point to Azure:

1. Migrate the sample schema.


To complete all the database objects like table schemas, indexes and stored procedures, we
need to extract schema from the source database and apply to the database. To extract schema,
you can use mysqldump with the --no-data parameter.

mysqldump -h [servername] -u [username] -p[password] --databases [db name] --no-data >


[schema file path]

2. To import schema to Azure Database for MySQL target, run the following command:

mysql.exe -h [servername] -u [username] -p[password] [database]< [schema file path]

3. If you have foreign keys in your schema, the initial load and continuous sync of the migration
will fail. Execute the following script in MySQL Workbench to extract the drop foreign key script
and add foreign key script.
4. Create a DMS instance. In the Azure portal, select + Create a resource, search for Azure
Database Migration Service, and then select Azure Database Migration Service . After the
service is created, locate it within the Azure portal, open it, and then create a new migration
project.

Enter Source Database details:


Enter target Azure Mysql database details:

Select the source and destination databases:


Run the migration:

Monitor the migration:


Start cut over:

Once the datas are synced begin cut over procedures by stopping connection to source
database. Then wait till the target is fully synced then switch connections to the target database
https://docs.microsoft.com/en-us/azure/dms/tutorial-mysql-azure-mysql-online

Challenges faced:
 Ensure that Source MySql server version is supported by Azure databases for Mysql
 Ensure that foreign keys are dropped before starting the migration initial load.
Having foreign keys in the database schema causes the initial load and continuous
sync to fail. You can add the foreign key after completion.
 Schema must match between source MySQL database and target database in Azure
Database for MySQL
 Binary logging should be enabled in the source database. By default binary logging
option will be disabled during MySql server installation.
 The user of the source database should have ReplicationAdmin role with the
privileges: REPLICATION CLIENT, REPLICATION REPLICA and SUPER if Mysql server
below 5.6.6
 Disable all triggers if any in the target database before migration start. You can
enable trigger after migration is done.

Other Possible limitations (from official Microsoft docs):

Online migration configuration

 The source MySQL Server version must be version 5.6.35, 5.7.18 or later

 Azure Database for MySQL supports:

o MySQL community edition


o InnoDB engine

 Same version migration. Migrating MySQL 5.6 to Azure Database for MySQL 5.7 isn't supported.

 Enable binary logging in my.ini (Windows) or my.cnf (Unix)

 User must have the ReplicationAdmin role.

 Collations defined for the source MySQL database are the same as the ones defined in target
Azure Database for MySQL.

 Schema must match between source MySQL database and target database in Azure Database
for MySQL.
 Schema in target Azure Database for MySQL must not have foreign keys.

 Schema in target Azure Database for MySQL must not have any triggers. 

Datatype limitations

 Limitation: If there's a JSON datatype in the source MySQL database, migration will fail during
continuous sync. Workaround: Modify JSON datatype to medium text or longtext in source
MySQL database.

 Limitation: If there's no primary key on tables, continuous sync will fail. Workaround:
Temporarily set a primary key for the table for migration to continue. You can remove the primary
key after data migration is complete.

LOB limitations

Large Object (LOB) columns are columns that could grow large in size. For MySQL, Medium text,
Longtext, Blob, Mediumblob, Longblob, etc. are some of the datatypes of LOB.

 Limitation: If LOB data types are used as primary keys, migration will fail. Workaround: Replace
primary key with other datatypes or columns that aren't LOB.

 Limitation: If the length of Large Object (LOB) column is bigger than 32 KB, data might be
truncated at the target. You can check the length of LOB column using this query: Workaround: If
you have LOB object that is bigger than 32 KB, contact engineering team at Ask Azure Database
Migrations

Other limitations

 A password string that has opening and closing curly brackets { } at the beginning and end of the
password string isn't supported. This limitation applies to both connecting to source MySQL and
target Azure Database for MySQL.

 The following DDLs aren't supported:

o All partition DDLs


o Drop table
o Rename table

 Using the alter table <table_name> add column <column_name> statement to add columns to


the beginning or to the middle of a table isn't supported. THe alter table <table_name> add
column <column_name> adds the column at the end of the table.
 Indexes created on only part of the column data aren't supported. The following statement is an
example that creates an index using only part of the column data:

 In DMS, the limit of databases to migrate in one single migration activity is four.

You might also like