- 关于 TiDB
- 主要概念
- 操作指南
- 快速上手
- 部署
- 配置
- 安全
- 安全传输层协议 (TLS)
- 生成自签名证书
- 监控
- 迁移
- 运维
- 扩容缩容
- 升级
- 故障诊断
- 参考手册
- SQL
- 与 MySQL 兼容性对比
- SQL 语言结构
- 数据类型
- 函数与操作符
- SQL 语句
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ALTER DATABASE
ALTER TABLE
ALTER USER
ANALYZE TABLE
BEGIN
CHANGE COLUMN
COMMIT
CREATE DATABASE
CREATE INDEX
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP TABLE
DROP USER
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RENAME INDEX
RENAME TABLE
REPLACE
REVOKE <privileges>
ROLLBACK
SELECT
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CREATE TABLE
SHOW DATABASES
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEXES [FROM|IN]
SHOW INDEX [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW SCHEMAS
SHOW STATUS
SHOW [FULL] TABLES
SHOW TABLE STATUS
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
START TRANSACTION
TRACE
TRUNCATE
UPDATE
USE
- 约束
- 生成列
- 字符集
- 配置
- tidb-server
- pd-server
- tikv-server
- 安全
- 事务
- 系统数据库
- 错误码
- 支持的连接器和 API
- 垃圾回收 (GC)
- 性能调优
- 监控指标
- 报警规则
- 最佳实践
- TiSpark 使用指南
- TiDB Binlog
- 周边工具
- 常见问题 (FAQ)
- 技术支持
- 贡献
- 版本发布历史
- 术语表
你正在查看 TiDB 数据库的较旧版本 (TiDB v2.1) 的文档。
TiDB Lightning 错误排解
当 Lightning 遇到不可恢复的错误时便会异常退出,并在日志中记下错误原因。一般可在日志底部找到,也可以搜索 [error]
字符串找出中间发生的错误。本文主要描述一些常见的错误及其解决方法。
导入速度太慢
TiDB Lightning 的正常速度为每条线程每 2 分钟导入一个 256 MB 的数据文件,如果速度远慢于这个数值就是有问题。导入的速度可以检查日志提及 restore chunk … takes
的记录,或者观察 Grafana 的监控信息。
导入速度太慢一般有几个原因:
原因 1:region-concurrency
设定太高,线程间争用资源反而减低了效率。
- 从日志的开头搜寻
region-concurrency
能知道 Lightning 读到的参数是多少。 - 如果 Lightning 与其他服务(如 Importer)共用一台服务器,必需手动将
region-concurrency
设为该服务器 CPU 数量的 75%。 - 如果 CPU 设有限额(例如从 K8s 指定的上限),Lightning 可能无法自动判断出来,此时亦需要手动调整
region-concurrency
。
原因 2:表结构太复杂。
每条索引都会额外增加 KV 对。如果有 N 条索引,实际导入的大小就差不多是 Mydumper 文件的 N+1 倍。如果索引不太重要,可以考虑先从 schema 去掉,待导入完成后再使用 CREATE INDEX
加回去。
原因 3:Lightning 版本太旧。
试试最新的版本吧!可能会有改善。
checksum failed: checksum mismatched remote vs local
原因:本地数据源跟目标数据库某个表的校验和不一致。这通常有更深层的原因:
这张表可能本身已有数据,影响最终结果。
如果目标数据库的校验和全是 0,表示没有发生任何导入,有可能是集群太忙无法接收任何数据。
如果数据源是由机器生成而不是从 Mydumper 备份的,需确保数据符合表的限制,例如:
- 自增 (AUTO_INCREMENT) 的列需要为正数,不能为 0。
- 单一键和主键 (UNIQUE and PRIMARY KEYs) 不能有重复的值。
解决办法:
使用
tidb-lightning-ctl
把出错的表删除,然后重启 Lightning 重新导入那些表。tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all
把断点存放在外部数据库(修改
[checkpoint] dsn
),减轻目标集群压力。
Checkpoint for … has invalid status:(错误码)
原因:断点续传已启用。Lightning 或 Importer 之前发生了异常退出。为了防止数据意外损坏,Lightning 在错误解决以前不会启动。
错误码是小于 25 的整数,可能的取值是 0、3、6、9、12、14、15、17、18、20、21。整数越大,表示异常退出所发生的步骤在导入流程中越晚。
解决办法:
如果错误原因是非法数据源,使用 tidb-lightning-ctl
删除已导入数据,并重启 Lightning。
tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all
其他解决方法请参考断点续传的控制。
ResourceTemporarilyUnavailable("Too many open engines …: 8")
原因:并行打开的引擎文件 (engine files) 超出 tikv-importer
里的限制。这可能由配置错误引起。即使配置没问题,如果 tidb-lightning
曾经异常退出,也有可能令引擎文件残留在打开的状态,占据可用的数量。
解决办法:
提高
tikv-importer.toml
内max-open-engines
的值。这个设置主要由内存决定,计算公式为:最大内存使用量 ≈
max-open-engines
×write-buffer-size
×max-write-buffer-number
降低
table-concurrency
+index-concurrency
,使之低于max-open-engines
。重启
tikv-importer
来强制移除所有引擎文件 (默认值为./data.import/
)。这样也会丢弃导入了一半的表,所以启动 Lightning 前必须清除过期的断点记录:tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all
cannot guess encoding for input file, please convert to UTF-8 manually
原因:Lightning 只支持 UTF-8 和 GB-18030 编码的表架构。此错误代表数据源不是这里任一个编码。也有可能是文件中混合了不同的编码,例如,因为在不同的环境运行过 ALTER TABLE
,使表架构同时出现 UTF-8 和 GB-18030 的字符。
解决办法:
- 编辑数据源,保存为纯 UTF-8 或 GB-18030 的文件。
- 手动在目标数量库创建所有的表,然后设置
[mydumper] no-schema = true
跳过创建表的步骤。 - 设置
[mydumper] character-set = "binary"
跳过这个检查。但是这样可能使数据库出现乱码。
[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'
原因: 一个 timestamp
类型的时间戳记录了不存在的时间值。时间值不存在是由于夏时制切换或超出支持的范围(1970 年 1 月 1 日至 2038 年 1 月 19 日)。
解决办法:
确保 Lightning 与数据源时区一致。
使用 TiDB Ansible 部署的话,修正 [
inventory.ini
] 下的timezone
变量。# inventory.ini [all:vars] timezone = Asia/Shanghai
手动部署的话,通过设定
$TZ
环境变量强制时区设定。# 强制使用 Asia/Shanghai 时区 TZ='Asia/Shanghai' bin/tidb-lightning -config tidb-lightning.toml
导出数据时,必须加上
--skip-tz-utc
选项。
- 导入速度太慢
- checksum failed: checksum mismatched remote vs local
- Checkpoint for … has invalid status:(错误码)
- ResourceTemporarilyUnavailable("Too many open engines …: 8")
- cannot guess encoding for input file, please convert to UTF-8 manually
- sql2kv sql encode error = types:1292invalid time format: '{1970 1 1 0 45 0 0}'