Azure Database for MySQL is a relational database service in the Microsoft cloud that is based on the MySQL Community Edition database engine. MySQL is an advanced, feature-rich, open-source database system that’s popular with developers, used for a wide range of applications, and compatible with the most popular application platforms.
Our flagship offering, Azure Database for MySQL – Flexible Server, is well-positioned to serve as the best platform for hosting your MySQL workloads, offering maximum control and flexibility to run your MySQL servers. We're now focusing all energies and feature investments towards Flexible Server, with Azure Database for MySQL - Single Server on path for retirement on 16 September 2024.
You can use Data-in replication in Azure Database for MySQL – Flexible server to synchronize data in an external MySQL server with an Azure Database for MySQL flexible server. The external server can be running on-premises, in virtual machines, in Azure Database for MySQL - Single Server, or even in a database service hosted by other cloud providers. Using Data-in replication also allows you to achieve minimal down-time for migrations from Single Server to Flexible Server.
In this blog post, I’ll explain how to migrate from Azure Database for MySQL - Single Server to Flexible Server with minimal downtime by using the ‘mysqlshell’ tool, an alternative to the mydumper/myloader tool. Mysqlshell, or ‘mysqlsh’, uses parallelism, which can speed up both the backup and restore process. This tool has shown promising results when used in a variety of scenarios with different database sizes.
Note: MySQLsh can also be used to migrate from VM, on-premises, different cloud vendors to Azure database for MySQL flexible server. However, selecting the best tool to address a specific migration scenario is a critical first step in the database migration journey, so be sure to refer to the blog post Selecting the best tool for migrating to Azure Database for MySQL – Flexible Server to understand the options available for your scenario.
The overall migration process includes the following high-level stages:
The following sections provide detail about each of these stages.
Note: This article references the term slave, which Microsoft no longer uses. When the term is removed from the software, we'll remove it from this article.
Before starting this process, be sure that the following prerequisites are in place.
Note: For information about creating an instance of MySQL – Flexible Server, see Create an Azure Database for MySQL flexible server.
Note: After replication is set up and the migration completes, you can delete this VM.
As I mentioned earlier, when you want to migrate from Azure Database for MySQL - Single Server to Flexible Server, you’ll likely want the migration to occur with minimal downtime. The best way to accomplish this is to create a replica of the source server, restore it to the target server instance, and then cut-over the application to point to new primary when the replica catches up source and there is no replication lag.
For the purposes of this post, I’m using an Azure Database for MySQL single server, which includes a single database (db1), as the source, and an Azure Database for MySQL flexile server as the target.
To configure Data-in replication between the source (Single Server) and the target (Flexible Server), perform the following steps.
mysqlsh --uri azureuser%40rahulsaha-single1-57@rahulsaha-single1-57.mysql.database.azure.com:3306
util.dumpInstance("/backup/mysqlsh/demo", {threads: 16, showProgress: true})
MySQL rahulsaha-single1-57.mysql.database.azure.com:3306 ssl JS > util.dumpInstance("/backup/mysqlsh/demo", {threads: 16, showProgress: true})
NOTE: Backup lock is not supported in MySQL 5.7 and DDL changes will not be blocked. The dump may fail with an error if schema changes are made while dumping.
Acquiring global read lock
Global read lock acquired
Initializing - done
2 out of 6 schemas will be dumped and within them 1 table, 0 views.
3 out of 5 users will be dumped.
Gathering information - done
All transactions have been started
Global read lock has been released
Writing global DDL files
Writing users DDL
NOTE: Could not select columns to be used as an index for table `db1`.`tab1`. Chunking has been disabled for this table, data will be dumped to a single file.
Running data dump using 16 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
103% (268.44M rows / ~259.06M rows), 1.33M rows/s, 13.28 MB/s uncompressed, 688.54 KB/s compressed
Dump duration: 00:03:35s
Total duration: 00:03:36s
Schemas dumped: 2
Tables dumped: 1
Uncompressed data size: 2.57 GB
Compressed data size: 128.54 MB
Compression ratio: 20.0
Rows written: 268435456
Bytes written: 128.54 MB
Average uncompressed throughput: 11.94 MB/s
Average compressed throughput: 596.41 KB/s
mysqlsh --uri azureuser@rahulsaha-flex1-57.mysql.database.azure.com:3306
util.loadDump("/backup/mysqlsh/demo", {threads: 16, showProgress: true})
CREATE USER 'replica_user'@'%' IDENTIFIED WITH mysql_native_password BY 'strong_pass';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
flush privileges;
Ping the source single server to identify the associated IP address, then note it.
For purposes of this post, the IP address of my source server is 20.81.113.52.
Ping the target flexible server to identify the associated IP address, then note it.
For purposes of this post, the IP address of the target server is 20.81.113.51.
On the target server, in the Azure portal, under Settings, select Networking, and then, under Firewall rules, add an entry for the IP address of the source single server.
After assuring that all the connectivity settings are in place, Data-in replication is properly configured from the source server to the target server, you are ready to configure and start replicating the changes from source database to the target server.
CALL mysql.az_replication_change_master('rahulsaha-single1-57.mysql.database.azure.com', 'replica_user@rahulsaha-single1-57', 'xxx', 3306, 'mysql-bin.000006', 657, '');
The following appears on screen:
+--------------------------------------------------------------------------------------------------+
| message |
+--------------------------------------------------------------------------------------------------+
| Successfully change the master. Please run "show slave status;" to check the replication status. |
+--------------------------------------------------------------------------------------------------+
1 row in set (3.07 sec)
Query OK, 0 rows affected (3.08 sec)
To start replication, at the mysql prompt, run the following command:
call mysql.az_replication_start;
The following appears on screen:
+------------------------------------------------------------------------------------------------------+
| message |
+------------------------------------------------------------------------------------------------------+
| Successfully start the replication. Please run "show slave status;" to check the replication status. |
+------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)
Query OK, 0 rows affected (0.06 sec)
While changes are being replicated to the replica DB server, check the (replication lag in seconds, Slave IO running, Slave SQL running, and the position of binlog and relay log) if the replica by running the following command:
mysql> show slave status\G
The following appears on screen:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: rahulsaha-single1-57.mysql.database.azure.com
Master_User: replica_user@rahulsaha-single1-57
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000006
Read_Master_Log_Pos: 3326
Relay_Log_File: relay_bin.000002
Relay_Log_Pos: 2989
Read_Master_Log_Pos: 3326
Relay_Log_File: relay_bin.000002
Relay_Log_Pos: 2989
Relay_Master_Log_File: mysql-bin.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: mysql.%,information_schema.%,performance_schema.%,sys.%
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 3326
Relay_Log_Space: 3190
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File: /app/work/primary_ca.pem
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2076890702
Master_UUID: b87e5f01-a3cd-11ed-ad86-3041b2bd9acc
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
After we set up replication, it is important to validate the replication. To validate replication, we can check the ‘slave status’ in replica. Additionally, we can check manually where we can create dummy objects in primary database instance and check the same object being replicated to replica.
To ensure a successful cutover, validate the replication and verify that there is zero lag. To do so, perform the following steps:
At this point, the migration is complete. Your applications are connected to the server running Azure Database for MySQL – Flexible Server.
We’ve now set up replication between the Azure Database for MySQL single server and the Azure Database for MySQL flexible server using the MySQL native Backup tool ‘mysqlsh’. Any changes to primary instance in the source single server are replicated to MySQL flexible server by using the native replication technique. Taking advantage of this solution, migration to Azure Database for MySQL - Flexible Server can be achieved from different sources such as VMs, on-premises, other cloud vendors, and Single Server with minimal downtime.
If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.