重要

你正在查看 TiDB v6.0 (DMR) 的文档。PingCAP 不提供基于 v6.0 的 bug 修复版本,如有 bug,会在后续版本中修复。

如无特殊需求,建议使用 TiDB 数据库的最新 LTS 版本

TiDB Lightning 使用前提

使用 TiDB Lightning 导入数据前,先检查环境是否满足要求,这有助于减少导入过程的错误,避免导入失败的情况。

下游数据库权限要求

TiDB Lightning 导入数据时,根据导入方式和启用特性等,需要下游数据库用户具备不同的权限,可参考下表:

特性作用域所需权限备注
必需基本功能目标 tableCREATE,SELECT,INSERT,UPDATE,DELETE,DROP,ALTERDROP 仅 tidb-lightning-ctl 在执行 checkpoint-destroy-all 时需要
目标 databaseCREATE
必需tidb-backendinformation_schema.columnsSELECT
local-backendmysql.tidbSELECT
-SUPER
-RESTRICTED_VARIABLES_ADMIN,RESTRICTED_TABLES_ADMIN当目标 TiDB 开启 SEM
推荐冲突检测,max-errorlightning.task-info-schema-name 配置的 schemaSELECT,INSERT,UPDATE,DELETE,CREATE,DROP如不需要,该值必须设为""
可选并行导入lightning.meta-schema-name 配置的 schemaSELECT,INSERT,UPDATE,DELETE,CREATE,DROP如不需要,该值必须设为""
可选checkpoint.driver = “mysql”checkpoint.schema 设置SELECT,INSERT,UPDATE,DELETE,CREATE,DROP使用数据库而非文件形式存放 checkpoint 信息时需要

下游数据库所需空间

目标 TiKV 集群必须有足够空间接收新导入的数据。除了标准硬件配置以外,目标 TiKV 集群的总存储空间必须大于 数据源大小 × 副本数量 × 2。例如集群默认使用 3 副本,那么总存储空间需为数据源大小的 6 倍以上。公式中的 2 倍可能难以理解,其依据是以下因素的估算空间占用:

  • 索引会占据额外的空间
  • RocksDB 的空间放大效应

目前无法精确计算 Dumpling 从 MySQL 导出的数据大小,但你可以用下面 SQL 语句统计信息表的 data_length 字段估算数据量:

统计所有 schema 大小,单位 MiB,注意修改 ${schema_name}

select table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}" group by table_schema;

统计最大单表,单位 MiB,注意修改 ${schema_name}

select table_name,table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}" group by table_name,table_schema order by sum  desc limit 5;

TiDB Lightning 运行时资源要求

操作系统:本文档示例使用的是若干新的、纯净版 CentOS 7 实例,你可以在本地虚拟化一台主机,或在供应商提供的平台上部署一台小型的云虚拟主机。TiDB Lightning 运行过程中,默认会占满 CPU,建议单独部署在一台主机上。如果条件不允许,你可以将 TiDB Lightning 和其他组件(比如tikv-server)部署在同一台机器上,然后设置region-concurrency 配置项的值为逻辑 CPU 数的 75%,以限制 TiDB Lightning 对 CPU 资源的使用。

内存和 CPU

TiDB Lightning 在不同 backend 模式下对 CPU 和内存的要求不同,在部署时,建议根据使用的 backend 选择合适的环境以获取最佳导入性能。

  • Local-backend:该模式对 CPU 和内存的需求都比较高,建议为 TiDB Lightning 分配 32 核以上的 CPU 和 64 GiB 以上内存。

说明:

导入大量数据时,一个并发对内存的占用在 2 GiB 左右,也就是说总内存占用最大可达到 region-concurrency * 2 GiB。region-concurrency 默认与逻辑 CPU 的数量相同。如果内存的大小(GiB)小于逻辑 CPU 数量的两倍或运行时出现 OOM,需要手动调低 region-concurrency 参数以避免 TiDB Lightning OOM。

  • TiDB-backend:该模式的主要性能瓶颈是 TiDB,建议分配 4 核 CPU 和 8GB 内存。如果实际导入时,发现 TiDB 集群并没有达到写入的上限,可以适当调大 region-concurrency 配置参数。
  • Importer-backend:资源消耗基本与 Local-backend 相同。不建议使用。如无特殊需求,请优先使用 Local-backend。

存储空间:配置项 sorted-kv-dir 设置排序的键值对的临时存放地址,目标路径必须是一个空目录,目录空间须大于待导入数据集的大小。建议与 data-source-dir 使用不同的存储设备,独占 IO 会获得更好的导入性能,且建议优先考虑配置闪存等高性能存储介质。

网络:建议使用带宽 >=10Gbps 的网卡。

文档内容是否有帮助?