Switch DM-worker Connection between Upstream MySQL Instances
When the upstream MySQL instance that DM-worker connects to needs downtime maintenance or when the instance crashes unexpectedly, you need to switch the DM-worker connection to another MySQL instance within the same migration group.
For more details on GTID set, refer to MySQL documentation.
Switch DM-worker connection via virtual IP
When DM-worker connects the upstream MySQL instance via a virtual IP (VIP), switching the VIP connection to another MySQL instance means switching the MySQL instance connected to DM-worker, without the upstream connection address changed.
To switch one upstream MySQL instance (when DM-worker connects to it via a VIP) to another, perform the following steps:
- Use the
query-status
command to get the GTID sets (relayBinlogGtid
) corresponding to the binlog that relay log has replicated from the old MySQL instance. Mark the sets asgtid-W
. - Use the
SELECT @@GLOBAL.gtid_purged;
command on the new MySQL instance to get the GTID sets corresponding to the purged binlogs. Mark the sets asgtid-P
. - Use the
SELECT @@GLOBAL.gtid_executed;
command on the new MySQL instance to get the GTID sets corresponding to all successfully executed transactions. Mark the sets asgtid-E
. - Make sure that the following conditions are met. Otherwise, you cannot switch the DM-work connection to the new MySQL instance:
gtid-W
containsgtid-P
.gtid-P
can be empty.gtid-E
containsgtid-W
.
- Use
pause-relay
to pause relay. - Use
pause-task
to pause all running tasks of data migration. - Change the VIP for it to direct at the new MySQL instance.
- Use
switch-relay-master
to tell relay to execute the primary-secondary switch. - Use
resume-relay
to make relay resume to read binlog from the new MySQL instance. - Use
resume-task
to resume the previous migration task.
Change the address of the upstream MySQL instance that DM-worker connects to
To make DM-worker connect to a new MySQL instance in the upstream by modifying the DM-worker configuration, perform the following steps:
- Use the
query-status
command to get the GTID sets (relayBinlogGtid
) corresponding to the binlog that relay log has replicated from the old MySQL instance. Mark this sets asgtid-W
. - Use the
SELECT @@GLOBAL.gtid_purged;
command on the new MySQL instance to get the GTID sets corresponding to the purged binlogs. Mark this sets asgtid-P
. - Use the
SELECT @@GLOBAL.gtid_executed;
command on the new MySQL instance to get the GTID sets corresponding to all successfully executed transactions. Mark this sets asgtid-E
. - Make sure that the following conditions are met. Otherwise, you cannot switch the DM-work connection to the new MySQL instance:
gtid-W
containsgtid-P
.gtid-P
can be empty.gtid-E
containsgtid-W
.
- Use
stop-task
to stop all running tasks of data migration. - Update the DM-worker configuration in the
inventory.ini
file and use DM-Ansible to perform a rolling upgrade on DM-worker. - Use
start-task
to restart the migration task.