- 关于 TiDB
- 主要概念
- 操作指南
- 快速上手
- 部署
- 配置
- 安全
- 安全传输层协议 (TLS)
- 生成自签名证书
- 监控
- 迁移
- 运维
- Ansible 常见运维操作
- 备份与恢复
- 定位异常查询
- 扩容缩容
- 升级
- 故障诊断
- 参考手册
- 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 INSTANCE
ALTER TABLE
ALTER USER
ANALYZE TABLE
BEGIN
CHANGE COLUMN
COMMIT
CREATE DATABASE
CREATE INDEX
CREATE ROLE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP ROLE
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CREATE TABLE
SHOW CREATE USER
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 REGIONS
SHOW TABLE STATUS
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SPLIT REGION
START TRANSACTION
TRACE
TRUNCATE
UPDATE
USE
- 约束
- 生成列
- 分区表
- 字符集
- SQL 模式
- 视图
- 配置
- tidb-server
- pd-server
- tikv-server
- 安全
- 事务
- 系统数据库
- 错误码
- 支持的连接器和 API
- 垃圾回收 (GC)
- 性能调优
- 监控指标
- 报警规则
- 最佳实践
- TiSpark 使用指南
- TiKV
- TiFlash
- TiDB Binlog
- 工具
- TiDB in Kubernetes
- 常见问题 (FAQ)
- 技术支持
- 贡献
- 版本发布历史
- 发布版本汇总
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 术语表
你正在查看 TiDB 数据库的较旧版本 (TiDB v3.1) 的文档。
TiDB Lightning 断点续传
大量的数据导入一般耗时数小时至数天,长时间运行的进程会有一定机率发生非正常中断。如果每次重启都从头开始,就会浪费掉之前已成功导入的数据。为此,Lightning 提供了“断点续传”的功能,即使 tidb-lightning
崩溃,在重启时仍然接着之前的进度继续工作。
本文主要介绍 TiDB Lightning 断点续传的启用与配置、断点的存储,以及断点续传的控制。
断点续传的启用与配置
[checkpoint]
# 启用断点续传。
# 导入时,Lightning 会记录当前进度。
# 若 Lightning 或其他组件异常退出,在重启时可以避免重复再导入已完成的数据。
enable = true
# 存储断点的方式
# - file:存放在本地文件系统(要求 v2.1.1 或以上)
# - mysql:存放在兼容 MySQL 的数据库服务器
driver = "file"
# 存储断点的架构名称(数据库名称)
# 仅在 driver = "mysql" 时生效
# schema = "tidb_lightning_checkpoint"
# 断点的存放位置
#
# 若 driver = "file",此参数为断点信息存放的文件路径。
# 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb`
#
# 若 driver = "mysql",此参数为数据库连接参数 (DSN),格式为“用户:密码@tcp(地址:端口)/”。
# 默认会重用 [tidb] 设置目标数据库来存储断点。
# 为避免加重目标集群的压力,建议另外使用一个兼容 MySQL 的数据库服务器。
# dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 导入成功后是否保留断点。默认为删除。
# 保留断点可用于调试,但有可能泄漏数据源的元数据。
# keep-after-success = false
断点的存储
TiDB Lightning 支持两种存储方式:本地文件或 MySQL 数据库。
若
driver = "file"
,断点会存放在一个本地文件,其路径由dsn
参数指定。由于断点会频繁更新,建议将这个文件放到写入次数不受限制的盘上,例如 RAM disk。若
driver = "mysql"
,断点可以存放在任何兼容 MySQL 5.7 或以上的数据库中,包括 MariaDB 和 TiDB。在没有选择的情况下,默认会存在目标数据库里。
目标数据库在导入期间会有大量的操作,若使用目标数据库来存储断点会加重其负担,甚至有可能造成通信超时丢失数据。因此,强烈建议另外部署一台兼容 MySQL 的临时数据库服务器。此数据库也可以安装在 tidb-lightning
的主机上。导入完毕后可以删除。
断点续传的控制
若 tidb-lightning
因不可恢复的错误而退出(例如数据出错),重启时不会使用断点,而是直接报错离开。为保证已导入的数据安全,这些错误必须先解决掉才能继续。使用 tidb-lightning-ctl
工具可以标示已经恢复。
--checkpoint-error-destroy
tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`'
该命令会让失败的表从头开始整个导入过程。选项中的架构和表名必须以反引号 (`
) 包裹,而且区分大小写。
如果导入
`schema`.`table`
这个表曾经出错,这条命令会:- 从目标数据库移除 (DROP) 这个表,清除已导入的数据。
- 将断点重设到“未开始”的状态。
如果
`schema`.`table`
没有出错,则无操作。
传入 "all" 会对所有表进行上述操作。这是最方便、安全但保守的断点错误解决方法:
tidb-lightning-ctl --checkpoint-error-destroy=all
--checkpoint-error-ignore
tidb-lightning-ctl --checkpoint-error-ignore='`schema`.`table`' &&
tidb-lightning-ctl --checkpoint-error-ignore=all
如果导入 `schema`.`table`
这个表曾经出错,这条命令会清除出错状态,如同没事发生过一样。传入 "all" 会对所有表进行上述操作。
除非确定错误可以忽略,否则不要使用这个选项。如果错误是真实的话,可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。
--checkpoint-remove
tidb-lightning-ctl --checkpoint-remove='`schema`.`table`' &&
tidb-lightning-ctl --checkpoint-remove=all
无论是否有出错,把表的断点清除。
--checkpoint-dump
tidb-lightning-ctl --checkpoint-dump=output/directory
将所有断点备份到传入的文件夹,主要用于技术支持。此选项仅于 driver = "mysql"
时有效。