- Table Routing
- Block and Allow Lists
- Binlog Event Filter
- Migration Delay Monitoring
- Usage Scenarios
- Manage the DM Cluster
- Manage Migration Tasks
- Migrate from MySQL-compatible Database
- DM Portal
This document details the advanced configuration of DM-worker.
# Worker Configuration. # Log configuration. log-level = "info" log-file = "dm-worker.log" # DM-worker listening address. worker-addr = ":8262" # Represents a MySQL/MariaDB instance or a replication group. source-id = "mysql-replica-01" # Server ID of secondary library for binlog replication. # Each instance (primary and secondary) in the replication group should have a different server ID. server-id = 101 # flavor: mysql/mariadb flavor = "mysql" # The directory used to store relay log. relay-dir = "./relay_log" # Enables gtid in the relay log unit. enable-gtid = false relay-binlog-name = "" relay-binlog-gtid = "" [from] host = "127.0.0.1" user = "root" password = "Up8156jArvIPymkVC+5LxkAT6rek" port = 3306 # Relay log purge strategy. [purge] interval = 3600 expires = 24 remain-space = 15 # Task status checker. [checker] check-enable = true backoff-rollback = "5m" backoff-max = "5m"
|Controls the log level: |
|Specifies the log file. If not specified, the logs are printed onto the standard output.|
|Specifies the address of DM-worker which provides services. You can omit the IP address and specify the port number only, such as ":8262".|
|Uniquely identifies a MySQL or MariaDB instance, or a replication group|
|Identifies the server ID of DM-worker as a MySQL or MariaDB secondary library. In a replication group, each instance (primary and secondary included) must have a unique server ID. In v1.0.2 and later versions, the |
|Indicates the release type of MySQL: |
|Specifies the relay log directory.|
|Determines whether DM-worker uses GTID to pull the binlog. If the upstream database has enabled the GTID mode and switching the DM-worker connection to another MySQL instance is needed, set it to |
|Specifies the file name from which DM-worker starts to pull the binlog. For example, |
|Specifies the GTID from which DM-worker starts to pull the binlog. For example, |
[from] section contains parameters that affect the connection to the upstream database.
|The host name of the upstream database.|
|The port number of the upstream database.|
|The username used to connect to the database.|
|The password used to connect to the database. Note: Use the password encrypted by dmctl.|
[purge] section contains parameters that affect the purge strategy of relay log.
Generally, there is no need to manually configure these parameters unless there is a large amount of relay logs and disk capacity is insufficient.
|Sets the time interval at which relay logs are regularly checked for expiration, in seconds.|
|Sets the expiration time for relay logs, in hours. The relay log that is not written by the relay processing unit, or does not need to be read by the existing data migration task will be deleted by DM if it exceeds the expiration time. If this parameter is not specified, the automatic purge is not performed.|
|Sets the minimum amount of free disk space, in gigabytes. When the available disk space is smaller than this value, DM-worker tries to delete relay logs.|
DM does not perform automatic purge when either of the following is true:
intervalis set to
remain-spaceare set to
[checker] section contains parameters that affect the task status checker.
|Determines whether to enable task status checker. If it is set to "true", DM tries to resume data migration task that is suspended due to errors.|
|Sets the time interval for adjusting the waiting time of the automatic recovery.|
|Sets the longest time interval for the automatic recovery after errors are detected.|
Generally, you only need to determine whether to enable the task status checker through the
check-enableparameter. It is not recommended to change the default values of
backoff-maxunless you have an in-depth understanding of these two parameters.