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

🪐 TiDB 技术问题 备份&数据迁移
,
1

【 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 个赞
2

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

3

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到其他的库再备份就没有卡住的现象了。

4

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

5

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

6

"[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”

7

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

9

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

10

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