We're pleased to announce preview of MySQL Server - Replicate Changes in Azure Database Migration Service. With a replicate changes migration, in conjunction with our offline scenario with “Enable Transactional Consistency", businesses can migrate their databases to Azure while the databases continue to be operational. In other words, migrations can be completed with minimum downtime for critical applications, limiting the impact to service level availability and inconvenience to their end customers. We also now support applying changes to a 5.7 target server.
The current implementation is based on streaming binlog changes from the source server and applying them to the target server. Similar to Data-in replication, this is easier to set up and doesn't require a physical connection between the source and the target servers.
Binlog can be sent by the server as a stream that contains binary data as documented here MySQL Internals Manual :: 14.9 Replication Protocol. The client can specify the initial log position to start the stream with. The log position is described by the log file name, the position within that file, and optionally GTID (Global Transaction ID) if gtid mode is enabled at the source.
The data changes are sent as "row" events, which contain data for individual rows (prior and/or after the change depending on the operation type, which is insert, delete, update). The row events are then applied in their raw format using a BINLOG statement: MySQL 8.0 Reference Manual :: 188.8.131.52 BINLOG Statement.
To complete the replicate changes migration successfully, ensure that the following prerequisites are in place:
You must run an offline migration scenario with “Enable Transactional Consistency" to get the bin log file and position to start replicating the incoming changes. The DMS portal UI shows the binary log filename and position aligned to the time the locks were obtained on the source for the consistent snapshot. We'll use this value in our replicate changes migration to begin streaming the incoming changes.
Now, start a new Replicate Changes activity.
Select the source.
Select your the flexible server target running version 8.0; servers running Single Server are filtered from the dropdown.
Enter the bin log position provided by the offline scenario.
Note: MySQL does not validate the initial binlog position and it will attempt to stream the binlog from any position it is told to. If an invalid value is specified, the server may report an unrelated error. For example, it may suggest increasing the "max_allowed_packet" value or even say that master is out of disk space. If you end up getting these types of errors, verify that the binlog position is specified correctly.
Ensure that you select the same database and tables that you selected for your offline migration.
In the Activity name text box, specify a name, and then select Start migration.
Monitor your migration and view the progress to determine when you can cutover with minimal downtime.
When your target is almost caught up with the source server, stop all incoming transactions to the source database, and then wait until all pending transactions have been applied to the target database. To confirm that the target database is up-to-date, on the source server, run the query 'SHOW MASTER STATUS;', and then compare that position to the position of the last committed binlog event (displayed under Migration Progress). When the two positions are the same, the target has caught up with all changes and you can start cutover.
In future releases, we'll include support for Azure MySQL single server as target, integrated online scenarios (offline+ catchup), so stay tuned!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.