Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: DM同步报错问题

[TiDB Usage Environment] Test
[TiDB Version] tidb-community-server-v7.0.0-linux-amd64
[Reproduction Path] DM, initial data was synchronized from MySQL to TiDB, but subsequent modifications in MySQL were not synchronized to TiDB.
[Encountered Problem: Phenomenon and Impact]
When checking the task status, the following error occurred:
[tidb@localhost ~]$ tiup dmctl --master-addr 192.168.0.81:8261 query-status 120spd
tiup is checking updates for component dmctl ...
Starting component `dmctl`: /home/tidb/.tiup/components/dmctl/v7.0.0/dmctl/dmctl --master-addr 192.168.0.81:8261 query-status 120spd
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-120",
"worker": "dm-192.168.0.83-8262",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "120spd",
"stage": "Paused",
"unit": "Sync",
"result": {
"isCanceled": false,
"errors": [
{
"ErrCode": 11001,
"ErrClass": "functional",
"ErrScope": "internal",
"ErrLevel": "high",
"Message": "parse mydumper metadata error: [code=11123:class=functional:scope=upstream:level=low], Message: didn't found binlog location in dumped metadata file metadata, Workaround: Please check log of dump unit, there maybe errors when read upstream binlog status, metadata: Started dump at: 2023-07-06 10:06:34\nFinished dump at: 2023-07-06 10:09:29\n",
"RawCause": "",
"Workaround": ""
}
],
"detail": null
},
"unresolvedDDLLockID": "",
"sync": {
"totalEvents": "0",
"totalTps": "0",
"recentTps": "0",
"masterBinlog": "",
"masterBinlogGtid": "",
"syncerBinlog": "(, 4)",
"syncerBinlogGtid": "",
"blockingDDLs": [
],
"unresolvedGroups": [
],
"synced": false,
"binlogType": "remote",
"secondsBehindMaster": "0",
"blockDDLOwner": "",
"conflictMsg": "",
"totalRows": "0",
"totalRps": "0",
"recentRps": "0"
},
"validation": null
}
]
}
]
}
[Resource Configuration]
Source configuration:
# Unique name, cannot be duplicated.
source-id: "mysql-120"
# Whether DM-worker uses Global Transaction Identifier (GTID) to pull binlog. The prerequisite is that the upstream MySQL has enabled GTID mode. If there is automatic master-slave switching upstream, GTID mode must be used.
enable-gtid: false
from:
host: "192.168.0.120" # For example: 172.16.10.81
user: "xxxxxx"
password: "xxxxxx" # Supports but not recommended to use plain text password, it is recommended to use dmctl encrypt to encrypt the plain text password before use
port: 3307
Task configuration:
# Task name, multiple tasks running simultaneously cannot have the same name.
name: "120spd"
# Task mode, can be set to
# full: only perform full data migration
# incremental: real-time synchronization of binlog
# all: full + binlog migration
task-mode: "all"
# Downstream TiDB configuration information.
target-database:
host: "192.168.0.81" # For example: 172.16.10.83
port: 4000
user: "root"
password: "xxxxxx" # Supports but not recommended to use plain text password, it is recommended to use dmctl encrypt to encrypt the plain text password before use
# All upstream MySQL instance configurations required for the current data migration task.
mysql-instances:
-
# Upstream instance or replication group ID.
source-id: "mysql-120"
# The configuration item name of the whitelist or blacklist of database names or table names to be migrated, used to reference the global whitelist or blacklist configuration. The global configuration is seen in the `block-allow-list` configuration below.
block-allow-list: "listA"
# Global configuration of whitelist and blacklist, each instance references through the configuration item name.
block-allow-list:
listA: # Name
do-tables: # Whitelist of upstream tables to be migrated.
- db-name: "test"
tbl-name: "*"
[Attachment: Screenshot/Log/Monitoring]