TiDB Lightning 报错

anan · 2020 年11 月 12 日 01:41

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

【TiDB 版本】：TiDB-v4.0.0 、tidb-toolkit-v4.0.2-linux-amd64
【问题描述】：恢复数据报错

image1908×731 85.4 KB

配置文件
[root@b7 bin]# cat tidb-lightning.toml
[lightning]

转换数据的并发数，默认为逻辑 CPU 数量，不需要配置。

混合部署的情况下可以配置为逻辑 CPU 的 75% 大小。

region-concurrency =

日志

level = “info”
file = “tidb-lightning.log”

[checkpoint]

是否启用断点续传。

导入数据时，TiDB Lightning 会记录当前表导入的进度。

所以即使 Lightning 或其他组件异常退出，在重启时也可以避免重复再导入已完成的数据。

enable = true

存储断点的数据库名称。

#schema = “tidb_lightning_checkpoint”

存储断点的方式。

- file：存放在本地文件系统。

- mysql：存放在兼容 MySQL 的数据库服务器。

driver = “file”

[tikv-importer]

backend 设置为 local 模式

backend = “local”
#backend = “tidb”
#on-duplicate = “ignore” # 或者 “error”、“ignore”

设置本地临时存储路径

sorted-kv-dir = “/disk1/bsppr”
range-concurrency = 1

[mydumper]

Mydumper 源数据目录。

data-source-dir = “/disk1/xpost”

[tidb]

目标集群的信息。tidb-server 的监听地址，填一个即可。

host = “192.168.241.7”
port = 4000
user = “root”
password = " "

表架构信息在从 TiDB 的“状态端口”获取。

status-port = 10080

pd-server 的地址，填一个即可

pd-addr = “192.168.241.49:12379”

这道题我不会 · 2020 年11 月 12 日 02:00

1.日志打印的信息是 “EpochNotMatch”，该错误是说 Region 的版本过期。TiDB 在请求 TiKV 时会在请求中附上 region 的 Epoch，KV 会校验 Epoch 如果不匹配则返回 EpochNotMatch 错误, 并在日志中返回最新 Region 信息。一般 TiDB 在收到报错后会进行 backoff 重试，所以这类 warn 信息通常可以忽略，你可以检查下数据是否已经成功导入；

2.补充信息：每个 Region 信息都有 Epoch 信息，包括两个字段:

conf_ver 代表配置项版本，当 region 发生 changepeer （即新增或删除 peer）时，该值会增加
version 代表 region 的版本，当 region 发生 split/merge 时，该值会增加

anan · 2020 年11 月 12 日 02:55

你好，想问下从mysql 备份恢复到tidb, 查单一字段查不到数据，select * 就可以。

这道题我不会 · 2020 年11 月 12 日 03:03

请问下其他字段单独查询都没有值还是只有字段 postid 没有值？方便提供一下表结构吗？

anan · 2020 年11 月 12 日 05:35

下面是表结构:

mysql> show create table xpost;

| xpost | CREATE TABLE xpost (
postid bigint(20) NOT NULL AUTO_INCREMENT,
facetid int(10) NOT NULL,
entryid int(10) NOT NULL,
title varchar(255) NOT NULL DEFAULT ‘’,
url varchar(512) NOT NULL,
abstract text DEFAULT NULL COMMENT ‘摘要’,
click int(11) DEFAULT 0 COMMENT ‘点击/阅读’,
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 COMMENT ‘字数’,
keywordcount int(11) DEFAULT NULL,
siteid int(11) DEFAULT 0,
domain varchar(60) DEFAULT ‘’,
author varchar(60) DEFAULT ‘’,
author_id varchar(60) DEFAULT ‘’ COMMENT ‘作者ID’,
posttime datetime NOT NULL,
include_t timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘入库时间’,
type tinyint(4) DEFAULT 0 COMMENT ‘positive/negtive/neutrual’,
source int(11) DEFAULT 0,
hidden tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘-3；识别噪音，-2:恢复误删数据, -1:已处理, 0: 未处理, 1:已删除, 2:正文噪音, 3:歧义噪音, 4:列表页噪音’,
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 COMMENT ‘正负面可信度’,
noise_rank tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘噪音可信度’,
device varchar(60) DEFAULT ‘’ COMMENT ‘发布设备’,
is_origin tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘是否原创 0：未知，1；原创，2：转载’,
is_top tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘是否头条 0：未知，1；是，2：否’,
media_type tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘媒体类型 0：未知，1；传统媒体，2：自媒体’,
author_type tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘作者类型 0：未知，1；KOL，2：官微 3：水军’,
content_type tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘内容类型 0：未知，1；PGC(营销声量)，2：UGC(自然声量)’,
client_type tinyint(4) NOT NULL DEFAULT 0 COMMENT ‘网站来源 0：未知，1；网页端，2：移动端’,
industry varchar(60) DEFAULT ‘’ COMMENT ‘行业’,
tags text DEFAULT NULL,
post_type tinyint(4) DEFAULT 0 COMMENT ‘内容类型 0：未知，1；PGC，2：UGC’,
type_reason varchar(256) DEFAULT ‘’ COMMENT ‘正负面规则命中原因’,
update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’,
origin_source varchar(64) DEFAULT ‘’ COMMENT ‘转载来源’,
media_id int(11) DEFAULT 0 COMMENT ‘媒体库ID’,
w_level tinyint(1) NOT NULL DEFAULT 0 COMMENT ‘预警等级’,
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 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=31409761974 |
±------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql>

这道题我不会 · 2020 年11 月 12 日 08:20

从现象上看怀疑索引数据有问题，麻烦执行下如下命令，检查下表数据和索引数据是否一致：

ADMIN CHECK TABLE tbl_name

anan · 2020 年11 月 12 日 08:32

mysql> ADMIN CHECK TABLE xpost;
ERROR 8003 (HY000): xpost err:[admin:8223]index: != record:&admin.RecordData{Handle:5001, Values:[]types.Datum{types.Datum{k:0x1, collation:"", decimal:0x0, length:0x0, i:30166, b:[]uint8(nil), x:interface {}(nil)}, types.Datum{k:0x5, collation:“utf8mb4_bin”, decimal:0x0, length:0x0, i:0, b:[]uint8{0x68, 0x74, 0x74, 0x70, 0x3a, 0x2f, 0x2f, 0x63, 0x70, 0x75, 0x2e, 0x62, 0x61, 0x69, 0x64, 0x75, 0x2e, 0x63, 0x6f, 0x6d, 0x2f, 0x70, 0x63, 0x2f, 0x31, 0x30, 0x32, 0x32, 0x2f, 0x32, 0x37, 0x35, 0x31, 0x32, 0x32, 0x37, 0x31, 0x36
mysql>

这道题我不会 · 2020 年11 月 12 日 08:46

从返回的结果看确实是索引在 Lightning 导入的时候有损坏，建议重新导入下数据；另外也建议升级下集群版本，当前集群 v4.0.0 版本有点低。

anan · 2020 年11 月 12 日 08:47

这种只能是重新导入吗？有工具可以修复吗

这道题我不会 · 2020 年11 月 12 日 08:53

可以考虑重建索引。

anan · 2020 年11 月 12 日 09:23

意思是在已恢复数据表上换个字段当索引吗？
这条命令可以修复吗 admin recover index [table_name] [index_name];

gaolei · 2020 年11 月 12 日 10:30

可以直接使用「admin repair table tablename」修复表里面遗漏的索引数据

anan · 2020 年11 月 12 日 10:42

好的,谢谢。我试下

anan · 2020 年11 月 13 日 01:58

是下面这条语句吗

gaolei · 2020 年11 月 13 日 02:37

对。不过在执行 recovery 之前建议先确认一下数据是不是都写入完毕了。可以执行一下

select count(*) from xpost

确认一下是否完全导入了，如果没有导入完成的话，还是建议重新 drop table 重新导入一次，否则重建索引也没有恢复所有的数据。

另外，如果大部分索引都没有创建成功的话，应该重新导入速度会更快。可以使用最新版的 lightning 重试一下，最近我们大幅优化了导入的稳定性，应该不会在遇到类似的错误导致导入失败的问题了。https://download.pingcap.org/tidb-toolkit-nightly-linux-amd64.tar.gz