dumpling备份导出失败

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

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：v4.0.9
  • 【问题描述】：
    备份时，预估的数据量是0，实际上有几千万数据。
    然后就会一直停在这，不动了。out文件夹里也没有数据（有库和表schema）。
    没有OOM的情况发生。

dumpling -h 127.0.0.1 -P 4000 -u root
-t 8
-F 200MiB
-r 500000
-T bsppr.xpost_bak
–read-timeout=3h
-o /disk1/bsppr_xpost_19/bsppr_xpost_19_1_1
–params “tidb_distsql_scan_concurrency=5”
–tidb-mem-quota-query 8589934592
–where “posttime>=‘2019-01-01 00:00:00’ and posttime<‘2019-02-05 00:00:00’”

image
image1574×250 13.1 KB

当我增大where的范围后，可以看到有预估数据了，但是导出会越来越慢，直到停止
–where “posttime>=‘2019-01-01 00:00:00’ and posttime<‘2020-01-01 00:00:00’”

image
image1501×263 13.5 KB

2

-r 设置 100，-t 设置32 -f 256
变量从 5 调整到 10

话说这个表结构和这段时间的数据量多少

3

调整了参数仍然不能正常导出。-r设置为100不现实。
每个自然月有5千万-2亿的数据量。

/*!40101 SET NAMES binary*/;
CREATE TABLE `xpost` (
  `postid` bigint(20) NOT NULL AUTO_INCREMENT,
  `facetid` int(10) NOT NULL,
  `entryid` int(10) NOT NULL,
  `title` varchar(255) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `url` varchar(512) COLLATE utf8mb4_bin NOT NULL,
  `abstract` text COLLATE utf8mb4_bin COMMENT '摘要',
  `click` int(11) DEFAULT '0' ,
  `reply` int(11) DEFAULT '0' COMMENT '回复/评论',
  `repost` int(11) DEFAULT '0' COMMENT '转发',
  `praise` int(11) DEFAULT '0' COMMENT '点赞',
  `collect` int(11) DEFAULT '0' COMMENT '收藏',
  `watch` int(11) DEFAULT NULL,
  `wordscount` int(11) DEFAULT '0',
  `keywordcount` int(11) DEFAULT NULL,
  `siteid` int(11) DEFAULT '0',
  `domain` varchar(60) COLLATE utf8mb4_bin DEFAULT '',
  `author` varchar(60) COLLATE utf8mb4_bin DEFAULT '',
  `author_id` varchar(60) COLLATE utf8mb4_bin DEFAULT '' ,
  `posttime` datetime NOT NULL,
  `include_t` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `type` tinyint(4) DEFAULT '0' COMMENT 'positive/negtive/neutrual',
  `source` int(11) DEFAULT '0',
  `hidden` tinyint(4) NOT NULL DEFAULT '0',
  `sourcetype` tinyint(4) NOT NULL,
  `crisis_post` tinyint(4) NOT NULL DEFAULT '0',
  `ontop` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否标记，0否1是',
  `type_rank` tinyint(4) NOT NULL DEFAULT '0' ,
  `noise_rank` tinyint(4) NOT NULL DEFAULT '0' ,
  `device` varchar(60) COLLATE utf8mb4_bin DEFAULT '',
  `is_origin` tinyint(4) NOT NULL DEFAULT '0',
  `is_top` tinyint(4) NOT NULL DEFAULT '0',
  `media_type` tinyint(4) NOT NULL DEFAULT '0',
  `author_type` tinyint(4) NOT NULL DEFAULT '0' ,
  `content_type` tinyint(4) NOT NULL DEFAULT '0',
  `client_type` tinyint(4) NOT NULL DEFAULT '0',
  `industry` varchar(60) COLLATE utf8mb4_bin DEFAULT '',
  `tags` text COLLATE utf8mb4_bin,
  `post_type` tinyint(4) DEFAULT '0' COMMENT '内容类型   0：未知，1；PGC，2：UGC',
  `type_reason` varchar(256) COLLATE utf8mb4_bin DEFAULT '' ,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ,
  `origin_source` varchar(64) COLLATE utf8mb4_bin DEFAULT '',
  `media_id` int(11) DEFAULT '0',
  `w_level` tinyint(1) NOT NULL DEFAULT '0' ,
  PRIMARY KEY (`postid`),
  UNIQUE KEY `idx_fid_url` (`facetid`,`url`),
  UNIQUE KEY `postid` (`postid`),
  KEY `idx_xpost_url` (`url`(255)),
  KEY `idx_xpost_entryid` (`entryid`),
  KEY `idx_xpost_type` (`type`),
  KEY `idx_xpost_sourcetype` (`sourcetype`),
  KEY `idx_xpost_pt` (`posttime`),
  KEY `idx_xpost_source` (`source`),
  KEY `idx_fid` (`facetid`)
) ENGINE=InnoDB AUTO_INCREMENT=35754662501 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC;
4

-r 的变小（1000？500？）会减少对 tidb 内存的占用，加速导出，试着多调整几次。-t 增加线程，会加速导出速度，并不是 -r 越大越好。如果导出 sql 变成慢语句。导出速度也会受到影响。

请问导出数据会被导入到哪里？

5

现在有两种需求，
一是：现在该表存有2年以上的数据，按照最佳实践中的方法，每一小limit1000来循环删除，删除速度过慢（每秒只能删除几百条）。因此打算按照每月分批次导出，然后按照需求的月份再导入回去一部分（不到一年）。
二是：把其中一部分有用的历史数据使用复杂sql过滤导出（大约4亿），存入mysql作为冷数据。但是也失败了，以下为导出csv的过程。

[tidb@b7 scripts]$ /home/tidb/tidb-toolkit-v4.0.9-linux-amd64/bin/dumpling \
> -u root \
> -h 127.0.0.1 \
> -P 4000 \
> -F 256MiB \
> -r 1000000 \
> -T bsppr.xpost_bak \
> -o /disk1/bsppr_xpost_19/bsppr_xpost_19_all \
> --filetype csv \
> --sql 'SELECT * from bsppr.xpost_bak WHERE entryid in (select entryid from bsppr.xentry where date BETWEEN "2019-01-01" and "2019-12-31" and  fid in (select id from xfacet where objectid in (SELECT objectid FROM bsppr..user_obj where ucid in (1010, 1368, 929))))'
Release version: v4.0.9
Git commit hash: 11d8d5dad31210a1ec6afef9d3c16b397f2fc9fb
Git branch:      heads/refs/tags/v4.0.9
Build timestamp: 2020-12-19 04:53:02Z
Go version:      go version go1.13 linux/amd64

[2021/01/14 09:18:26.927 +08:00] [INFO] [config.go:598] ["detect server type"] [type=TiDB]
[2021/01/14 09:18:26.927 +08:00] [INFO] [config.go:617] ["detect server version"] [version=4.0.9]
[2021/01/14 09:18:26.939 +08:00] [INFO] [client.go:166] ["[pd] create pd client with endpoints"] [pd-address="[192.168.241.49:12379,192.168.241.26:12379,192.168.241.24:12379]"]
[2021/01/14 09:18:26.941 +08:00] [INFO] [base_client.go:236] ["[pd] update member urls"] [old-urls="[http://192.168.241.49:12379,http://192.168.241.26:12379,http://192.168.241.24:12379]"] [new-urls="[http://192.168.241.24:12379,http://192.168.241.26:12379,http://192.168.241.49:12379]"]
[2021/01/14 09:18:26.941 +08:00] [INFO] [base_client.go:252] ["[pd] switch leader"] [new-leader=http://192.168.241.24:12379] [old-leader=]
[2021/01/14 09:18:26.941 +08:00] [INFO] [base_client.go:102] ["[pd] init cluster id"] [cluster-id=6584703571713496467]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x8b036b]

goroutine 220 [running]:
sync.(*RWMutex).RLock(...)
	sync/rwmutex.go:48
database/sql.(*Rows).ColumnTypes(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	database/sql/sql.go:2861 +0x5b
github.com/pingcap/dumpling/v4/export.setTableMetaFromRows(0x0, 0x0, 0xc000123fc0, 0xc0008e0c90, 0x2403e60)
	github.com/pingcap/dumpling@/v4/export/ir.go:94 +0x40
github.com/pingcap/dumpling/v4/export.(*Writer).WriteTableData.func1(0x2403e60, 0xc0008bea20)
	github.com/pingcap/dumpling@/v4/export/writer.go:180 +0xadb
github.com/pingcap/br/pkg/utils.WithRetry(0x2443580, 0xc000123fc0, 0xc00094fc70, 0x2422840, 0xc00004f0a0, 0x0, 0x0)
	github.com/pingcap/br@v0.0.0-20201119111016-600102357a27/pkg/utils/retry.go:34 +0x7c
github.com/pingcap/dumpling/v4/export.(*Writer).WriteTableData(0xc0000d79e0, 0x2464180, 0xc00017aa80, 0x2443a80, 0xc00013ec80, 0x0, 0x1, 0x1)
	github.com/pingcap/dumpling@/v4/export/writer.go:161 +0x1d2
github.com/pingcap/dumpling/v4/export.(*Writer).handleTask(0xc0000d79e0, 0x2403d80, 0xc0002849c0, 0x1, 0x1)
	github.com/pingcap/dumpling@/v4/export/writer.go:104 +0x31b
github.com/pingcap/dumpling/v4/export.(*Writer).run(0xc0000d79e0, 0xc0000d7800, 0x0, 0x0)
	github.com/pingcap/dumpling@/v4/export/writer.go:86 +0x15c
github.com/pingcap/dumpling/v4/export.(*Dumper).startWriters.func4(0xc0008a7768, 0x0)
	github.com/pingcap/dumpling@/v4/export/dump.go:235 +0x33
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc00049bb90, 0xc000972ea0)
	golang.org/x/sync@v0.0.0-20200625203802-6e8e738ad208/errgroup/errgroup.go:57 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go
	golang.org/x/sync@v0.0.0-20200625203802-6e8e738ad208/errgroup/errgroup.go:54 +0x66
6

Panic 的问题是 dumpling 的 bug。我们已经提了 PR 在修复这个问题。
没有 OOM 情况发生是通过检查 TiDB 的日志得出的结论吗？

7

没有拿到 dmesg，so。。。

8

可以用 dumpling v4.0.8 使用 --sql 导出这个试试

9

以前的导出确实有OOM发生，是我搞错了。

–sql使用这个方法可以解决复杂sql导出问题。为了加速我把一年的数据拆分为12个月分别导出。

10

感谢反馈 :pray: 有新的问题创建新的问答帖子。

11

不过导出的insert语句有问题。
insert into 后面没有表名。不方便数据导回，我用sed -i 加上了表名后导入mysql，部分内容出现编码错误。
如果使用loader等其他工具，回提示没有schema文件。

[root@b30 bsppr_xpost_19_fed02]# head result.0000000000000.sql 

/*!40101 SET NAMES binary*/;
INSERT INTO `` (`postid`,`facetid`,`entryid`,`title`,`url`,`abstract`,`click`,`reply`,`repost`,`praise`,`collect`,`watch`,`wordscount`,`keywordcount`,`siteid`,`domain`,`author`,`author_id`,`posttime`,`include_t`,`type`,`source`,`hidden`,`sourcetype`,`crisis_post`,`ontop`,`type_rank`,`noise_rank`,`device`,`is_origin`,`is_top`,`media_type`,`author_type`,`content_type`,`client_type`,`industry`,`tags`,`post_type`,`type_reason`,`update_time`,`origin_source`,`media_id`,`w_level`,`screen_show`,`warn_level`,`topping`,`toptime`) VALUES
以下忽略

[root@b30 bsppr_xpost_19_fed01]# mysql -uroot -p < result.0000000000000.sql 

ERROR 1366 (HY000) at line 75014: Incorrect string value: '\xE6\x98\xA5\xE5\x8D\x8E...' for column 'abstract' at row 632


[root@b30 bsppr_xpost_19_fed01]# mysql -uroot -p< result.0000000000001.sql 

ERROR 1406 (22001) at line 174103: Data too long for column 'abstract' at row 886
12

这个是期望中的情况，–sql 的时候不会去解析 sql，如果 sql 里包含多表联合查询 dumpling 也不知道这里给什么表名比较好。
这里你可以手动创建一份 schema-create.sql 语句试试。

13

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