tidb dm 全量备份报错

dm full全量备份报错,check没报错

$ tiup dmctl --master-addr 192.168.241.58:8261 query-status task29-full
Found dmctl newer version:

The latest version:         v6.0.0
Local installed version:    v2.0.7
Update current component:   tiup update dmctl
Update all components:      tiup update --all

Starting component dmctl: /home/tidb/.tiup/components/dmctl/v2.0.7/dmctl/dmctl --master-addr 192.168.241.58:8261 query-status task29-full
{
“result”: true,
“msg”: “”,
“sources”: [
{
“result”: true,
“msg”: “”,
“sourceStatus”: {
“source”: “mysql-29”,
“worker”: “dm-192.168.241.60-8262”,
“result”: null,
“relayStatus”: null
},
“subTaskStatus”: [
{
“name”: “task29-full”,
“stage”: “Paused”,
“unit”: “Load”,
“result”: {
“isCanceled”: false,
“errors”: [
{
“ErrCode”: 10006,
“ErrClass”: “database”,
“ErrScope”: “downstream”,
“ErrLevel”: “high”,
“Message”: “run table schema failed - dbfile ./dumped_data.task29-full/crisis_admin.auth_group-schema.sql: execute statement failed: USE crisis_admin;”,
“RawCause”: “Error 1049: Unknown database ‘crisis_admin’”,
“Workaround”: “”
}
],
“detail”: null
},
“unresolvedDDLLockID”: “”,
“load”: {
“finishedBytes”: “700325509”,
“totalBytes”: “13395222433”,
“progress”: “5.23 %”,
“metaBinlog”: “(mysql-bin.000002, 1001233434)”,
“metaBinlogGTID”: “”
}
}
]
}
]
}

请问能贴一下任务配置吗?

可以,是这个yaml文件吗? check-task是过了的呀

[tidb@b16 task_29_to_tidb]$ more task29-full.yaml

任务名,多个同时运行的任务不能重名。

name: “task29-full”

任务模式,可设为

full:只进行全量数据迁移

incremental: binlog 实时同步

all: 全量 + binlog 迁移

task-mode: “full”

下游 TiDB 配置信息。

target-database:
host: “192.168.241.26” # 例如:172.16.10.83
port: 4000
user: “root”
password: “DAlSkK6R0weiBy” # 支持但不推荐使用明文密码,建议使用 dmctl encrypt 对明文密码进行加密后使用

当前数据迁移任务需要的全部上游 MySQL 实例配置。

mysql-instances:

上游实例或者复制组 ID。

source-id: “mysql-29”

需要迁移的库名或表名的黑白名单的配置项名称,用于引用全局的黑白名单配置,全局配置见下面的 block-allow-list 的配置。

block-allow-list: “listA”

黑白名单全局配置,各实例通过配置项名引用。

block-allow-list:
listA: # 名称
do-dbs: [“notice”,“crisis_admin”,“pitaya”]
[tidb@b16 task_29_to_tidb]$

check-task 只是用来保证您填写的配置是否符合一些硬性要求(比如,用了 incremental mode 就必须配置 source meta),同步过程中可能存在的错误(比如,syncer 拉到了一条不符合 row format 的 binlog)就没有办法发现了。

从报错来看,应该是 crisis_admin-schema-create.sql 文件缺失。这个文件在 dump 阶段由 dumper 创建;导入时,loader 会先根据这个文件创建一个对应的库,然后在恢复这个库里的表。目前最简单的处理方法就是手动在下游创建这些库,然后重启任务;或者尝试 start-task --remove-meta 的方式重启任务。

p.s. 2.0 版本的 dm 太古老了,建议升级一下,不然很难排查问题:joy:

1 个赞

好的,感谢大佬 :kiss::kiss::kiss:!!

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。