Skip to content

Latest commit

 

History

History
52 lines (40 loc) · 4.41 KB

usage-scenario-master-slave-switch.md

File metadata and controls

52 lines (40 loc) · 4.41 KB
Raw
title summary
Switch DM-worker Connection between Upstream MySQL Instances
Learn how to switch the DM-worker connection between upstream MySQL instances.

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.

Note:

  • You can switch the DM-worker connection to only an instance within the same primary-secondary migration cluster.
  • The MySQL instance to be newly connected to must have the binlog required by DM-worker.
  • DM-worker must operate in the GTID sets mode, which means you must specify enable-gtid: true in the corresponding source configuration file.
  • The connection switch only supports the following two scenarios. Strictly follow the procedures for each scenario. Otherwise, you might have to re-deploy the DM cluster according to the newly connected MySQL instance and perform the data migration task all over again.

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.

Note:

Make necessary changes to DM in this scenario. Otherwise, when you switch the VIP connection to another MySQL instance, DM might connect to the new and old MySQL instances at the same time in different connections. In this situation, the binlog replicated to DM is not consistent with other upstream status that DM receives, causing unpredictable anomalies and even data damage.

To switch one upstream MySQL instance (when DM-worker connects to it via a VIP) to another, perform the following steps:

  1. Use the query-status command to get the GTID sets (syncerBinlogGtid) corresponding to the binlog that the current processing unit of binlog replication has replicated to the downstream. Mark the sets as gtid-S.
  2. 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 as gtid-P.
  3. 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 as gtid-E.
  4. Make sure that the following conditions are met. Otherwise, you cannot switch the DM-work connection to the new MySQL instance:
    • gtid-S contains gtid-P. gtid-P can be empty.
    • gtid-E contains gtid-S.
  5. Use pause-task to pause all running tasks of data migration.
  6. Change the VIP for it to direct at the new MySQL instance.
  7. 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:

  1. Use the query-status command to get the GTID sets (syncerBinlogGtid) corresponding to the binlog that the current processing unit of binlog replication has replicated to the downstream. Mark this sets as gtid-S.
  2. 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 as gtid-P.
  3. 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 as gtid-E.
  4. Make sure that the following conditions are met. Otherwise, you cannot switch the DM-work connection to the new MySQL instance:
    • gtid-S contains gtid-P. gtid-P can be empty.
    • gtid-E contains gtid-S.
  5. Use stop-task to stop all running tasks of data migration.
  6. Use the operator-source stop command to remove the source configuration corresponding to the address of the old MySQL instance from the DM cluster.
  7. Update the address of the MySQL instance in the source configuration file and use the operate-source create command to reload the new source configuration in the DM cluster.
  8. Use start-task to restart the migration task.