用dumplings导出数据,中间没有报错,但是一直没有进行下去,卡在某一个表里面

【 TiDB 使用环境】测试环境 【 TiDB 版本】v4.0.9 【遇到的问题】用dumplings导出数据,中间没有报错,但是一直没有进行下去,卡在某一个表里面 【复现路径】做过哪些操作出现的问题`
数据库test是使用lightning还原的(用dumplings从MySQL5.7导出的),使用一段时间之后,想用dumplings导出test库到SQL文件,但是使用dumplings导出的时候一直卡住,没有往下进行,目前GC设置是10分钟,也尝试过将GC设置成720h,但是也是一样,卡在了这里。
dumplings导出命令如下:(导出schema很快就完成了,但是导出数据或者结构+数据会卡住)
/data/tidb-toolkit-v4.0.9-linux-amd64/bin/dumpling -u test -p test123456 -P 4000 -h 172.16.48.238 -B test --filetype sql -t 4 -o /data/test/data -r 200000 -F 256MiB --loglevel “debug” --tidb-mem-quota-query 8589934592 --no-schemas &
【问题现象及影响】
【附件】

  • 相关日志、配置文件、Grafana 监控(https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控(如有 BR、TiDB-binlog、TiCDC 等)
  • 对应模块日志(包含问题前后 1 小时日志)
    日志如下:
    [2022/05/20 12:53:41.883 +08:00] [DEBUG] [dump.go:259] [“start dumping table…”] [table=dcs_ua]
    [2022/05/20 12:53:41.951 +08:00] [DEBUG] [dump.go:392] [“send task to writer”] [task=“meta of table ‘test’.‘dcs_ua’”]
    [2022/05/20 12:53:42.017 +08:00] [DEBUG] [dump.go:406] [“split chunks”] [query=“SELECT MIN(ua_id),MAX(ua_id) FROM test.dcs_ua”]
    [2022/05/20 12:53:42.018 +08:00] [DEBUG] [dump.go:331] [“get int bounding values”] [lower=5234403] [upper=7839303]
    [2022/05/20 12:53:42.019 +08:00] [INFO] [dump.go:336] [“get estimated rows count”] [estimateCount=17698]
    [2022/05/20 12:53:42.019 +08:00] [DEBUG] [dump.go:339] [“skip concurrent dump due to estimate count < rows”] [“estimate count”=17698] [conf.rows=200000]
    [2022/05/20 12:53:42.095 +08:00] [DEBUG] [dump.go:392] [“send task to writer”] [task=“data of table ‘test’.‘dcs_ua’(0/1)”]
    [2022/05/20 12:53:42.095 +08:00] [DEBUG] [dump.go:259] [“start dumping table…”] [table=dcs_xingbake_recovery_phone_number]
    [2022/05/20 14:08:29.365 +08:00] [DEBUG] [dump.go:757] [“update PD safePoint limit with ttl”] [safePoint=433329906475073564] [ttl=300]
    [2022/05/20 14:10:59.365 +08:00] [DEBUG] [dump.go:757] [“update PD safePoint limit with ttl”] [safePoint=433329906475073564] [ttl=300]

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1 个赞

请问有确认过 dumpling 过程中,生成的 file 文件的大小是否是持续增长的。我理解如果是卡住,说明两个情况,一种执行 SQL 查询已经卡住,一种是正在进行导出工作,所以通过日志看是卡住的,需要通过生成的 file 文件的大小是否还在增加判断。

data文件夹内的数据一直都是300K,备份的数据并不会持续的增长,dumplings的命令也是一直在运行的,也有进到数据库里面查询,也没有发现持续的任务。
之后无论怎么重复执行都是只有300K的数据,因为可以导出表结构,所以考虑不是表结构的问题,可能是某些表内的数据的问题,后面通过对每个表进行一次select操作,发现有部分表有
”[components/tidb_query/src/batch/executors/table_scan_executor.rs:338]: Data is corrupted, missing data for NOT NULL column (offset = 6)“ 和 ”Failed to decode row v2 data as i64“ 的报错,将有这些报错的表rename到其他的库再备份就没有卡住的现象了。

您好,麻烦发下表结构,和数据加载方式:客户端 insert 还是 load 工具加载的,什么工具。

如果可以的话,最好再来点儿脱敏后的数据。

"[components/tidb_query/src/batch/executors/table_scan_executor.rs:338]: Data is corrupted, missing data for NOT NULL column (offset = 11)"报错的表,表结构如下:

SHOW CREATE TABLE role_bak

CREATE TABLE role_bak (
role_id int(10) NOT NULL AUTO_INCREMENT COMMENT ‘’,
role_name varchar(255) NOT NULL DEFAULT ‘’ COMMENT ‘’,
role_pid int(10) DEFAULT NULL COMMENT ‘’,
role_type tinyint(2) NOT NULL DEFAULT ‘0’ COMMENT ‘’,
add_time int(10) DEFAULT ‘0’ COMMENT ‘’,
update_time int(10) DEFAULT ‘0’ COMMENT ‘’,
department_id int(11) DEFAULT ‘0’ COMMENT ‘’,
state tinyint(4) DEFAULT ‘1’ COMMENT ‘’,
platform_id tinyint(2) DEFAULT ‘1’ COMMENT ‘’,
creator_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘’,
creator_type varchar(16) NOT NULL DEFAULT ‘admin’ COMMENT ‘’,
role_company_id int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘’,
PRIMARY KEY (role_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=2852005 COMMENT=’’

SHOW CREATE TABLE role

CREATE TABLE role (
role_id int(10) NOT NULL AUTO_INCREMENT COMMENT ‘’,
role_name varchar(255) NOT NULL DEFAULT ‘’ COMMENT ‘’,
role_pid int(10) DEFAULT NULL COMMENT ‘’,
role_type tinyint(2) NOT NULL DEFAULT ‘0’ COMMENT ‘’,
add_time int(10) DEFAULT ‘0’ COMMENT ‘’,
update_time int(10) DEFAULT ‘0’ COMMENT ‘’,
department_id int(11) DEFAULT ‘0’ COMMENT ‘’,
state tinyint(4) DEFAULT ‘1’ COMMENT ‘’,
platform_id tinyint(2) DEFAULT ‘1’ COMMENT ‘’,
creator_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘创建者id’,
creator_type varchar(16) NOT NULL DEFAULT ‘admin’ COMMENT ‘’,
role_company_id int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘’,
role_no varchar(128) NOT NULL DEFAULT ‘’ COMMENT ‘’,
PRIMARY KEY (role_id),
KEY idx_company_id (role_company_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=302203 COMMENT=’’

报错的是role_bak表,role表是后面重新导入的,对比之后发现,应该是有其他的同事直接用线上的表BR还原到TEST环境

"Failed to decode row v2 data as u64"报错的表,表结构如下:

CREATE TABLE test_user_observer_invitation_bak (
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT ‘’,
observer_id INT(11) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘’,
survey_id BIGINT(20) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘’,
is_editable TINYINT(3) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘’,
status TINYINT(3) NOT NULL DEFAULT ‘1’ COMMENT ‘’,
login_time INT(11) NOT NULL DEFAULT ‘0’ COMMENT ‘’,
ip VARCHAR(100) NOT NULL DEFAULT ‘’ COMMENT ‘’,
modify_time INT(11) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘’,
add_time INT(11) NOT NULL DEFAULT ‘0’ COMMENT ‘’,
PRIMARY KEY (id),
KEY survey_id (survey_id)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=240001 COMMENT=’’

正常的数据如下:
“id” “observer_id” “survey_id” “is_editable” “status” “login_time” “ip” “modify_time” “add_time”
“20” “3” “2865627” “0” “1” “1631103056” “127.0.0.1” “1631103056” “1631087272”
“21” “2” “2866197” “0” “1” “1631088993” “127.0.0.1” “1631088993” “1631087802”
“22” “4” “2866203” “0” “1” “1631158011” “127.0.0.1” “1631158011” “1631152192”
“23” “2” “2866220” “0” “1” “1631183153” “127.0.0.1” “1631183153” “1631177859”
“24” “3” “2866246” “0” “1” “1631187118” “127.0.0.1” “1631187118” “1631156617”

明确一下, role_bak 在测试环境,是由生产环境的 role 通过 br 备份后又还原到 测试环境的 role_bak,对吗?
test_user_observer_invitation_bak 表是如何加载数据的?

是的, role_bak 这个表本来是test环境的 role 表,之前有人使用了生产BR的数据恢复到了测试环境,导致 role 表报错,我将这个 rolerenamerole_bak 表,然后用 dumplings 导回去
test_user_observer_invitation 本来是通过 dumplings 导入的,后面应该也是因为 BR 的影响,导致无法无法使用

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