From 8321d07b4a06c8c0bdcb3cb2bf11abb2e9feabd6 Mon Sep 17 00:00:00 2001 From: anotherrachel Date: Thu, 6 Feb 2020 15:24:35 +0800 Subject: [PATCH 1/4] tidb-lightning: add glossary --- dev/TOC.md | 1 + .../tools/tidb-lightning/glossary.md | 192 ++++++++++++++++++ 2 files changed, 193 insertions(+) create mode 100644 dev/reference/tools/tidb-lightning/glossary.md diff --git a/dev/TOC.md b/dev/TOC.md index 31257a6a02e0..a12bedd4d85e 100644 --- a/dev/TOC.md +++ b/dev/TOC.md @@ -354,6 +354,7 @@ - [监控告警](/dev/reference/tools/tidb-lightning/monitor.md) - [故障诊断](/dev/how-to/troubleshoot/tidb-lightning.md) - [FAQ](/dev/faq/tidb-lightning.md) + - [TiDB Lightning 术语表](/dev/reference/tools/tidb-lightning/glossary.md) - [sync-diff-inspector](/dev/reference/tools/sync-diff-inspector/overview.md) - [PD Control](/dev/reference/tools/pd-control.md) - [PD Recover](/dev/reference/tools/pd-recover.md) diff --git a/dev/reference/tools/tidb-lightning/glossary.md b/dev/reference/tools/tidb-lightning/glossary.md new file mode 100644 index 000000000000..255d339b0e74 --- /dev/null +++ b/dev/reference/tools/tidb-lightning/glossary.md @@ -0,0 +1,192 @@ +--- +title: TiDB Lightning 术语表 +summary: 了解 TiDB Lightning 相关的术语及定义。 +category: glossary +--- + +# TiDB Lightning 术语表 + +本术语表提供了 TiDB Lightning 相关的术语和定义，这些术语会出现在 TiDB Lightning 的日志、监控指标、配置和文档中。 + + + +## A + +### Analyze + +统计信息分析。指重建 TiDB 表中的数据信息，即运行 [`ANALYZE TABLE`](/dev/reference/sql/statements/analyze-table.md) 语句。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 + +### `AUTO_INCREMENT_ID` + +用于为自增列分配默认值的计数器，每张表都有一个相关联的 `AUTO_INCREMENT_ID`。在 TiDB 中，该计数器还用于分配行 ID。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有 `AUTO_INCREMENT_ID` 列，该步总是执行。 + + + +## B + +### Backend + +也称作 Back end（后端），用于接受 TiDB Lightning 解析结果。 + +详情参阅 [TiDB Lightning TiDB-backend](/dev/reference/tools/tidb-lightning/tidb-backend.md)。 + +### Black-white list + +黑白名单配置列表。用于指定要导入、忽略哪些表和库。 + +详情参阅 [TiDB Lightning 表库过滤](/dev/reference/tools/tidb-lightning/table-filter.md)。 + + + +## C + +### Checkpoint + +断点。用于保证 TiDB Lightning 在导入数据时不断地将进度保存到本地文件或远程数据库中。这样即使进程崩溃，TiDB Lightning 也能从中间状态恢复。 + +详情参见 [TiDB Lightning 断点续传](/dev/reference/tools/tidb-lightning/checkpoints.md)。 + +### Checksum + +校验和。一种用于[验证导入数据](/dev/faq/tidb-lightning.md#如何校验导入的数据的正确性)正确性的方法。 + +在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个KV对的内容计算得出。这些数字分别是： + +* 键值对的数量 +* 所有键值对的长度 +* 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 + +TiDB Lightning 通过比较每个表的[本地校验和](/dev/reference/tools/tidb-lightning/glossary.md#local-checksum)和[远程校验和](/dev/reference/tools/tidb-lightning/glossary.md#remote-checksum)来验证导入数据的正确性。如果有任一校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将`post-restore.checksum` 设置为 `false` 。 + +遇到校验和不匹配的问题时，参考[故障排查](/dev/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 + +### Chunk + +指数据源中的单个文件。 + +### Compaction + +压缩。指将多个小 SST 文件合并为一个大 SST 文件并清理已删除的条目。TiDB Lightning 导入数据时，TiKV 在后台会自动压缩数据。 + +> **注意：** +> +> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是该操作的相关设置默认是禁用的。 +> 技术细节参阅 [RocksDB 关于压缩的说明](https://github.com/facebook/rocksdb/wiki/Compaction)。 + + + +## D + +### Data engine + +数据引擎。用于对实际的行数据进行排序的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)。 + +当一个表数据很多的时候，表的数据会被放置在多个数据引擎中以改善任务流水线并节省 TiKV Importer 的空间。默认条件下，每 100 GB 的 SQL 数据会打开一个新的数据引擎（可通过 `mydumper.batch-size` 配置项进行更改）。 + +TiDB Lightning 同时处理多个数据引擎（可通过 `lightning.table-concurrency` 配置项进行更改）。 + + + +## E + +### Engine + +引擎。在 TiKV Importer 中，一个引擎就是一个用于排序键值对的 RocksDB 实例。 + +TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 Ingest 做准备。 + +引擎使用 TiKV Importer 的 `import-dir` 作为临时存储，有时也会被称为引擎文件 (engine files)。 + +另见[数据引擎](/dev/reference/tools/tidb-lightning/glossary.md#data-engine)和[索引引擎](/dev/reference/tools/tidb-lightning/glossary.md#index-engine)。 + + + +## I + +### Import mode + +导入模式。指通过降低读取速度和空间使用优化 TiKV 写入的配置模式。 + +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](/dev/reference/tools/tidb-lightning/glossary.md#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/dev/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后-tidb-集群变得又慢又耗-cpu)。 + +### Index engine + +索引引擎。用于对索引进行排序的[引擎](#engine)。 + +不管表中有多少索引，每张表都对应一个索引引擎。 + +TiDDB Lightning 可同时处理多个索引引擎（可通过`lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 + +### Ingest + +指将 [SST 文件](#sst-file)的全部内容插入到 RocksDB（TiKV）store 中的操作。 + +与逐个插入键值对相比，Ingest 的效率非常高。因此，该操作直接决定了 TiDB Lightning 的性能。 + +技术细节参阅 [RocksDB's 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 + + + +## K + +### KV pair + +即 key-value pair（键值对）。 + +### KV encoder + +用于将 SQL 或 CSV 行解析为键值对的例程。多个 KV encoder 会并行运行以加快处理速度。 + + + +## L + +### Local checksum + +本地校验和。在将键值对发送到 TiKV Importer 前，由 TiDB Lightning 计算的表的校验和。 + + + +## N + +### Normal mode + +普通模式。未启用[导入模式](/dev/reference/tools/tidb-lightning/glossary.md#import-mode)时的模式。 + + + +## P + +### Post-processing + +指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) [SST 文件](/dev/reference/tools/tidb-lightning/glossary.md#sst-file)。 + + + +## R + +### Remote checksum + +远程校验和。指导入 TiDB 后所计算的表的[校验和](/dev/reference/tools/tidb-lightning/glossary.md#checksum)。 + + + +## S + +### Scattering + +指随机分配 [Region](/dev/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 + +### Splitting + +指 TiKV Importer 在上传之前会将引擎拆分为若干小 SST 文件的操作。这是因为引擎通常分大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/dev/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 + +### SST file + +Sorted string table file（排序字符串表文件）。一种在 RocksDB 中（因而也是 TiKV 的）键值对集合在本机的存储形式。 + +TiKV Importer 从关闭的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) 到 TiKV store 中。 \ No newline at end of file From a72a9de4f87cd904e1d7157118792d73cca259a5 Mon Sep 17 00:00:00 2001 From: anotherrachel Date: Wed, 12 Feb 2020 19:34:56 +0800 Subject: [PATCH 2/4] address comments Co-Authored-By: kennytm --- dev/TOC.md | 2 +- dev/reference/tools/tidb-lightning/glossary.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dev/TOC.md b/dev/TOC.md index a12bedd4d85e..02c811c88954 100644 --- a/dev/TOC.md +++ b/dev/TOC.md @@ -354,7 +354,7 @@ - [监控告警](/dev/reference/tools/tidb-lightning/monitor.md) - [故障诊断](/dev/how-to/troubleshoot/tidb-lightning.md) - [FAQ](/dev/faq/tidb-lightning.md) - - [TiDB Lightning 术语表](/dev/reference/tools/tidb-lightning/glossary.md) + - [术语表](/dev/reference/tools/tidb-lightning/glossary.md) - [sync-diff-inspector](/dev/reference/tools/sync-diff-inspector/overview.md) - [PD Control](/dev/reference/tools/pd-control.md) - [PD Recover](/dev/reference/tools/pd-recover.md) diff --git a/dev/reference/tools/tidb-lightning/glossary.md b/dev/reference/tools/tidb-lightning/glossary.md index 255d339b0e74..02256e9dc182 100644 --- a/dev/reference/tools/tidb-lightning/glossary.md +++ b/dev/reference/tools/tidb-lightning/glossary.md @@ -22,7 +22,7 @@ category: glossary 用于为自增列分配默认值的计数器，每张表都有一个相关联的 `AUTO_INCREMENT_ID`。在 TiDB 中，该计数器还用于分配行 ID。 -因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有 `AUTO_INCREMENT_ID` 列，该步总是执行。 +因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 @@ -54,7 +54,7 @@ category: glossary 校验和。一种用于[验证导入数据](/dev/faq/tidb-lightning.md#如何校验导入的数据的正确性)正确性的方法。 -在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个KV对的内容计算得出。这些数字分别是： +在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个键值对的内容计算得出。这些数字分别是： * 键值对的数量 * 所有键值对的长度 @@ -119,7 +119,7 @@ TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先 不管表中有多少索引，每张表都对应一个索引引擎。 -TiDDB Lightning 可同时处理多个索引引擎（可通过`lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 +TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 ### Ingest @@ -127,7 +127,7 @@ TiDDB Lightning 可同时处理多个索引引擎（可通过`lightning.index-co 与逐个插入键值对相比，Ingest 的效率非常高。因此，该操作直接决定了 TiDB Lightning 的性能。 -技术细节参阅 [RocksDB's 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 +技术细节参阅 [RocksDB 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 @@ -189,4 +189,4 @@ TiDDB Lightning 可同时处理多个索引引擎（可通过`lightning.index-co Sorted string table file（排序字符串表文件）。一种在 RocksDB 中（因而也是 TiKV 的）键值对集合在本机的存储形式。 -TiKV Importer 从关闭的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) 到 TiKV store 中。 \ No newline at end of file +TiKV Importer 从关闭的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) 到 TiKV store 中。 From 03e8ddcd1c1e30f81cdd317e6755276134d83bfc Mon Sep 17 00:00:00 2001 From: anotherrachel Date: Fri, 14 Feb 2020 19:39:30 +0800 Subject: [PATCH 3/4] Apply suggestions from code review Co-Authored-By: Keke Yi <40977455+yikeke@users.noreply.github.com> --- .../tools/tidb-lightning/glossary.md | 39 ++++++++++--------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/dev/reference/tools/tidb-lightning/glossary.md b/dev/reference/tools/tidb-lightning/glossary.md index 02256e9dc182..4f2611e8de78 100644 --- a/dev/reference/tools/tidb-lightning/glossary.md +++ b/dev/reference/tools/tidb-lightning/glossary.md @@ -14,13 +14,13 @@ category: glossary ### Analyze -统计信息分析。指重建 TiDB 表中的数据信息，即运行 [`ANALYZE TABLE`](/dev/reference/sql/statements/analyze-table.md) 语句。 +统计信息分析。指重建 TiDB 表中的统计信息，即运行 [`ANALYZE TABLE`](/dev/reference/sql/statements/analyze-table.md) 语句。 因为 TiDB Lightning 不通过 TiDB 导入数据，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 ### `AUTO_INCREMENT_ID` -用于为自增列分配默认值的计数器，每张表都有一个相关联的 `AUTO_INCREMENT_ID`。在 TiDB 中，该计数器还用于分配行 ID。 +用于为自增列分配默认值的自增 ID 计数器。每张表都有一个相关联的 `AUTO_INCREMENT_ID` 计数器。在 TiDB 中，该计数器还用于分配行 ID。 因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 @@ -52,15 +52,15 @@ category: glossary ### Checksum -校验和。一种用于[验证导入数据](/dev/faq/tidb-lightning.md#如何校验导入的数据的正确性)正确性的方法。 +校验和。一种用于[验证导入数据正确性](/dev/faq/tidb-lightning.md#如何校验导入的数据的正确性)的方法。 在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个键值对的内容计算得出。这些数字分别是： * 键值对的数量 -* 所有键值对的长度 +* 所有键值对的总长度 * 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 -TiDB Lightning 通过比较每个表的[本地校验和](/dev/reference/tools/tidb-lightning/glossary.md#local-checksum)和[远程校验和](/dev/reference/tools/tidb-lightning/glossary.md#remote-checksum)来验证导入数据的正确性。如果有任一校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将`post-restore.checksum` 设置为 `false` 。 +TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将`post-restore.checksum` 设置为 `false` 。 遇到校验和不匹配的问题时，参考[故障排查](/dev/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 @@ -74,7 +74,8 @@ TiDB Lightning 通过比较每个表的[本地校验和](/dev/reference/tools/ti > **注意：** > -> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是该操作的相关设置默认是禁用的。 +> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是官方不推荐采用该操作，且该操作的相关设置默认是禁用的。 +> > 技术细节参阅 [RocksDB 关于压缩的说明](https://github.com/facebook/rocksdb/wiki/Compaction)。 @@ -83,7 +84,7 @@ TiDB Lightning 通过比较每个表的[本地校验和](/dev/reference/tools/ti ### Data engine -数据引擎。用于对实际的行数据进行排序的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)。 +数据引擎。用于对实际的行数据进行排序的[引擎](#engine)。 当一个表数据很多的时候，表的数据会被放置在多个数据引擎中以改善任务流水线并节省 TiKV Importer 的空间。默认条件下，每 100 GB 的 SQL 数据会打开一个新的数据引擎（可通过 `mydumper.batch-size` 配置项进行更改）。 @@ -97,11 +98,11 @@ TiDB Lightning 同时处理多个数据引擎（可通过 `lightning.table-concu 引擎。在 TiKV Importer 中，一个引擎就是一个用于排序键值对的 RocksDB 实例。 -TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 Ingest 做准备。 +TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 [Ingest](#ingest) 做准备。 引擎使用 TiKV Importer 的 `import-dir` 作为临时存储，有时也会被称为引擎文件 (engine files)。 -另见[数据引擎](/dev/reference/tools/tidb-lightning/glossary.md#data-engine)和[索引引擎](/dev/reference/tools/tidb-lightning/glossary.md#index-engine)。 +另见[数据引擎](#data-engine)和[索引引擎](#index-engine)。 @@ -109,15 +110,15 @@ TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先 ### Import mode -导入模式。指通过降低读取速度和空间使用优化 TiKV 写入的配置模式。 +导入模式。指通过降低读取速度和减少空间使用，来优化 TiKV 写入的配置模式。 -导入过程中，TiDB Lightning 自动在导入模式和[普通模式](/dev/reference/tools/tidb-lightning/glossary.md#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/dev/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后-tidb-集群变得又慢又耗-cpu)。 +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/dev/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后-tidb-集群变得又慢又耗-cpu)。 ### Index engine 索引引擎。用于对索引进行排序的[引擎](#engine)。 -不管表中有多少索引，每张表都对应一个索引引擎。 +不管表中有多少索引，每张表都只对应**一个**索引引擎。 TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 @@ -155,7 +156,7 @@ TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-co ### Normal mode -普通模式。未启用[导入模式](/dev/reference/tools/tidb-lightning/glossary.md#import-mode)时的模式。 +普通模式。未启用[导入模式](#import-mode)时的模式。 @@ -163,7 +164,7 @@ TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-co ### Post-processing -指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) [SST 文件](/dev/reference/tools/tidb-lightning/glossary.md#sst-file)。 +指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](#ingest) [SST 文件](#sst-file)。 @@ -171,7 +172,7 @@ TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-co ### Remote checksum -远程校验和。指导入 TiDB 后所计算的表的[校验和](/dev/reference/tools/tidb-lightning/glossary.md#checksum)。 +远程校验和。指导入 TiDB 后所计算的表的[校验和](#checksum)。 @@ -179,14 +180,14 @@ TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-co ### Scattering -指随机分配 [Region](/dev/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 +指随机再分配 [Region](/dev/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 ### Splitting -指 TiKV Importer 在上传之前会将引擎拆分为若干小 SST 文件的操作。这是因为引擎通常分大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/dev/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 +指 TiKV Importer 在上传之前会将单个引擎文件拆分为若干小 [SST 文件](#sst-file)的操作。这是因为引擎文件通常很大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/dev/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 ### SST file -Sorted string table file（排序字符串表文件）。一种在 RocksDB 中（因而也是 TiKV 的）键值对集合在本机的存储形式。 +Sorted string table file（排序字符串表文件）。SST 文件是一种在 RocksDB 中（因而也是 TiKV 中）键值对集合在本地的存储形式。 -TiKV Importer 从关闭的[引擎](/dev/reference/tools/tidb-lightning/glossary.md#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](/dev/reference/tools/tidb-lightning/glossary.md#ingest) 到 TiKV store 中。 +TiKV Importer 从关闭的[引擎](#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](#ingest) 到 TiKV store 中。 From f1db475e68fdf9bc76a1fa0990dc9ffc03898ed9 Mon Sep 17 00:00:00 2001 From: anotherrachel Date: Fri, 14 Feb 2020 22:00:17 +0800 Subject: [PATCH 4/4] update other versions --- .../tools/tidb-lightning/glossary.md | 4 +- v2.1/TOC.md | 1 + .../tools/tidb-lightning/glossary.md | 187 +++++++++++++++++ v3.0/TOC.md | 1 + .../tools/tidb-lightning/glossary.md | 193 ++++++++++++++++++ v3.1/TOC.md | 1 + .../tools/tidb-lightning/glossary.md | 193 ++++++++++++++++++ 7 files changed, 578 insertions(+), 2 deletions(-) create mode 100644 v2.1/reference/tools/tidb-lightning/glossary.md create mode 100644 v3.0/reference/tools/tidb-lightning/glossary.md create mode 100644 v3.1/reference/tools/tidb-lightning/glossary.md diff --git a/dev/reference/tools/tidb-lightning/glossary.md b/dev/reference/tools/tidb-lightning/glossary.md index 4f2611e8de78..c467770e48f9 100644 --- a/dev/reference/tools/tidb-lightning/glossary.md +++ b/dev/reference/tools/tidb-lightning/glossary.md @@ -60,7 +60,7 @@ category: glossary * 所有键值对的总长度 * 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 -TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将`post-restore.checksum` 设置为 `false` 。 +TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将 `post-restore.checksum` 设置为 `false` 。 遇到校验和不匹配的问题时，参考[故障排查](/dev/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 @@ -112,7 +112,7 @@ TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先 导入模式。指通过降低读取速度和减少空间使用，来优化 TiKV 写入的配置模式。 -导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/dev/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后-tidb-集群变得又慢又耗-cpu)。 +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/dev/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后tidb-集群变得又慢又耗-cpu)。 ### Index engine diff --git a/v2.1/TOC.md b/v2.1/TOC.md index 194fad31ec83..30c62df766a9 100644 --- a/v2.1/TOC.md +++ b/v2.1/TOC.md @@ -323,6 +323,7 @@ - [监控告警](/v2.1/reference/tools/tidb-lightning/monitor.md) - [故障诊断](/v2.1/how-to/troubleshoot/tidb-lightning.md) - [FAQ](/v2.1/faq/tidb-lightning.md) + - [术语表](/v2.1/reference/tools/tidb-lightning/glossary.md) - [sync-diff-inspector](/v2.1/reference/tools/sync-diff-inspector/overview.md) - [PD Control](/v2.1/reference/tools/pd-control.md) - [PD Recover](/v2.1/reference/tools/pd-recover.md) diff --git a/v2.1/reference/tools/tidb-lightning/glossary.md b/v2.1/reference/tools/tidb-lightning/glossary.md new file mode 100644 index 000000000000..bda7810e762b --- /dev/null +++ b/v2.1/reference/tools/tidb-lightning/glossary.md @@ -0,0 +1,187 @@ +--- +title: TiDB Lightning 术语表 +summary: 了解 TiDB Lightning 相关的术语及定义。 +category: glossary +--- + +# TiDB Lightning 术语表 + +本术语表提供了 TiDB Lightning 相关的术语和定义，这些术语会出现在 TiDB Lightning 的日志、监控指标、配置和文档中。 + + + +## A + +### Analyze + +统计信息分析。指重建 TiDB 表中的统计信息，即运行 [`ANALYZE TABLE`](/v2.1/reference/sql/statements/analyze-table.md) 语句。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 + +### `AUTO_INCREMENT_ID` + +用于为自增列分配默认值的自增 ID 计数器。每张表都有一个相关联的 `AUTO_INCREMENT_ID` 计数器。在 TiDB 中，该计数器还用于分配行 ID。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 + + + +## B + +### Black-white list + +黑白名单配置列表。用于指定要导入、忽略哪些表和库。 + +详情参阅 [TiDB Lightning 表库过滤](/v2.1/reference/tools/tidb-lightning/table-filter.md)。 + + + +## C + +### Checkpoint + +断点。用于保证 TiDB Lightning 在导入数据时不断地将进度保存到本地文件或远程数据库中。这样即使进程崩溃，TiDB Lightning 也能从中间状态恢复。 + +详情参见 [TiDB Lightning 断点续传](/v2.1/reference/tools/tidb-lightning/checkpoints.md)。 + +### Checksum + +校验和。一种用于[验证导入数据正确性](/v2.1/faq/tidb-lightning.md#如何校验导入的数据的正确性)的方法。 + +在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个键值对的内容计算得出。这些数字分别是： + +* 键值对的数量 +* 所有键值对的总长度 +* 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 + +TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将 `post-restore.checksum` 设置为 `false` 。 + +遇到校验和不匹配的问题时，参考[故障排查](/v2.1/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 + +### Chunk + +指数据源中的单个文件。 + +### Compaction + +压缩。指将多个小 SST 文件合并为一个大 SST 文件并清理已删除的条目。TiDB Lightning 导入数据时，TiKV 在后台会自动压缩数据。 + +> **注意：** +> +> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是官方不推荐采用该操作，且该操作的相关设置默认是禁用的。 +> +> 技术细节参阅 [RocksDB 关于压缩的说明](https://github.com/facebook/rocksdb/wiki/Compaction)。 + + + +## D + +### Data engine + +数据引擎。用于对实际的行数据进行排序的[引擎](#engine)。 + +当一个表数据很多的时候，表的数据会被放置在多个数据引擎中以改善任务流水线并节省 TiKV Importer 的空间。默认条件下，每 100 GB 的 SQL 数据会打开一个新的数据引擎（可通过 `mydumper.batch-size` 配置项进行更改）。 + +TiDB Lightning 同时处理多个数据引擎（可通过 `lightning.table-concurrency` 配置项进行更改）。 + + + +## E + +### Engine + +引擎。在 TiKV Importer 中，一个引擎就是一个用于排序键值对的 RocksDB 实例。 + +TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 [Ingest](#ingest) 做准备。 + +引擎使用 TiKV Importer 的 `import-dir` 作为临时存储，有时也会被称为引擎文件 (engine files)。 + +另见[数据引擎](#data-engine)和[索引引擎](#index-engine)。 + + + +## I + +### Import mode + +导入模式。指通过降低读取速度和减少空间使用，来优化 TiKV 写入的配置模式。 + +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/v2.1/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后tidb-集群变得又慢又耗-cpu)。 + +### Index engine + +索引引擎。用于对索引进行排序的[引擎](#engine)。 + +不管表中有多少索引，每张表都只对应**一个**索引引擎。 + +TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 + +### Ingest + +指将 [SST 文件](#sst-file)的全部内容插入到 RocksDB（TiKV）store 中的操作。 + +与逐个插入键值对相比，Ingest 的效率非常高。因此，该操作直接决定了 TiDB Lightning 的性能。 + +技术细节参阅 [RocksDB 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 + + + +## K + +### KV pair + +即 key-value pair（键值对）。 + +### KV encoder + +用于将 SQL 或 CSV 行解析为键值对的例程。多个 KV encoder 会并行运行以加快处理速度。 + + + +## L + +### Local checksum + +本地校验和。在将键值对发送到 TiKV Importer 前，由 TiDB Lightning 计算的表的校验和。 + + + +## N + +### Normal mode + +普通模式。未启用[导入模式](#import-mode)时的模式。 + + + +## P + +### Post-processing + +指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](#ingest) [SST 文件](#sst-file)。 + + + +## R + +### Remote checksum + +远程校验和。指导入 TiDB 后所计算的表的[校验和](#checksum)。 + + + +## S + +### Scattering + +指随机再分配 [Region](/v2.1/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 + +### Splitting + +指 TiKV Importer 在上传之前会将单个引擎文件拆分为若干小 [SST 文件](#sst-file)的操作。这是因为引擎文件通常很大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/v2.1/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 + +### SST file + +Sorted string table file（排序字符串表文件）。SST 文件是一种在 RocksDB 中（因而也是 TiKV 中）键值对集合在本地的存储形式。 + +TiKV Importer 从关闭的[引擎](#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](#ingest) 到 TiKV store 中。 diff --git a/v3.0/TOC.md b/v3.0/TOC.md index 1d9dca094b4d..104a433097cf 100644 --- a/v3.0/TOC.md +++ b/v3.0/TOC.md @@ -351,6 +351,7 @@ - [监控告警](/v3.0/reference/tools/tidb-lightning/monitor.md) - [故障诊断](/v3.0/how-to/troubleshoot/tidb-lightning.md) - [FAQ](/v3.0/faq/tidb-lightning.md) + - [术语表](/v3.0/reference/tools/tidb-lightning/glossary.md) - [sync-diff-inspector](/v3.0/reference/tools/sync-diff-inspector/overview.md) - [PD Control](/v3.0/reference/tools/pd-control.md) - [PD Recover](/v3.0/reference/tools/pd-recover.md) diff --git a/v3.0/reference/tools/tidb-lightning/glossary.md b/v3.0/reference/tools/tidb-lightning/glossary.md new file mode 100644 index 000000000000..7ed4ff16f45b --- /dev/null +++ b/v3.0/reference/tools/tidb-lightning/glossary.md @@ -0,0 +1,193 @@ +--- +title: TiDB Lightning 术语表 +summary: 了解 TiDB Lightning 相关的术语及定义。 +category: glossary +--- + +# TiDB Lightning 术语表 + +本术语表提供了 TiDB Lightning 相关的术语和定义，这些术语会出现在 TiDB Lightning 的日志、监控指标、配置和文档中。 + + + +## A + +### Analyze + +统计信息分析。指重建 TiDB 表中的统计信息，即运行 [`ANALYZE TABLE`](/v3.0/reference/sql/statements/analyze-table.md) 语句。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 + +### `AUTO_INCREMENT_ID` + +用于为自增列分配默认值的自增 ID 计数器。每张表都有一个相关联的 `AUTO_INCREMENT_ID` 计数器。在 TiDB 中，该计数器还用于分配行 ID。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 + + + +## B + +### Backend + +也称作 Back end（后端），用于接受 TiDB Lightning 解析结果。 + +详情参阅 [TiDB Lightning TiDB-backend](/v3.0/reference/tools/tidb-lightning/tidb-backend.md)。 + +### Black-white list + +黑白名单配置列表。用于指定要导入、忽略哪些表和库。 + +详情参阅 [TiDB Lightning 表库过滤](/v3.0/reference/tools/tidb-lightning/table-filter.md)。 + + + +## C + +### Checkpoint + +断点。用于保证 TiDB Lightning 在导入数据时不断地将进度保存到本地文件或远程数据库中。这样即使进程崩溃，TiDB Lightning 也能从中间状态恢复。 + +详情参见 [TiDB Lightning 断点续传](/v3.0/reference/tools/tidb-lightning/checkpoints.md)。 + +### Checksum + +校验和。一种用于[验证导入数据正确性](/v3.0/faq/tidb-lightning.md#如何校验导入的数据的正确性)的方法。 + +在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个键值对的内容计算得出。这些数字分别是： + +* 键值对的数量 +* 所有键值对的总长度 +* 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 + +TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将 `post-restore.checksum` 设置为 `false` 。 + +遇到校验和不匹配的问题时，参考[故障排查](/v3.0/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 + +### Chunk + +指数据源中的单个文件。 + +### Compaction + +压缩。指将多个小 SST 文件合并为一个大 SST 文件并清理已删除的条目。TiDB Lightning 导入数据时，TiKV 在后台会自动压缩数据。 + +> **注意：** +> +> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是官方不推荐采用该操作，且该操作的相关设置默认是禁用的。 +> +> 技术细节参阅 [RocksDB 关于压缩的说明](https://github.com/facebook/rocksdb/wiki/Compaction)。 + + + +## D + +### Data engine + +数据引擎。用于对实际的行数据进行排序的[引擎](#engine)。 + +当一个表数据很多的时候，表的数据会被放置在多个数据引擎中以改善任务流水线并节省 TiKV Importer 的空间。默认条件下，每 100 GB 的 SQL 数据会打开一个新的数据引擎（可通过 `mydumper.batch-size` 配置项进行更改）。 + +TiDB Lightning 同时处理多个数据引擎（可通过 `lightning.table-concurrency` 配置项进行更改）。 + + + +## E + +### Engine + +引擎。在 TiKV Importer 中，一个引擎就是一个用于排序键值对的 RocksDB 实例。 + +TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 [Ingest](#ingest) 做准备。 + +引擎使用 TiKV Importer 的 `import-dir` 作为临时存储，有时也会被称为引擎文件 (engine files)。 + +另见[数据引擎](#data-engine)和[索引引擎](#index-engine)。 + + + +## I + +### Import mode + +导入模式。指通过降低读取速度和减少空间使用，来优化 TiKV 写入的配置模式。 + +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/v3.0/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后tidb-集群变得又慢又耗-cpu)。 + +### Index engine + +索引引擎。用于对索引进行排序的[引擎](#engine)。 + +不管表中有多少索引，每张表都只对应**一个**索引引擎。 + +TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 + +### Ingest + +指将 [SST 文件](#sst-file)的全部内容插入到 RocksDB（TiKV）store 中的操作。 + +与逐个插入键值对相比，Ingest 的效率非常高。因此，该操作直接决定了 TiDB Lightning 的性能。 + +技术细节参阅 [RocksDB 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 + + + +## K + +### KV pair + +即 key-value pair（键值对）。 + +### KV encoder + +用于将 SQL 或 CSV 行解析为键值对的例程。多个 KV encoder 会并行运行以加快处理速度。 + + + +## L + +### Local checksum + +本地校验和。在将键值对发送到 TiKV Importer 前，由 TiDB Lightning 计算的表的校验和。 + + + +## N + +### Normal mode + +普通模式。未启用[导入模式](#import-mode)时的模式。 + + + +## P + +### Post-processing + +指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](#ingest) [SST 文件](#sst-file)。 + + + +## R + +### Remote checksum + +远程校验和。指导入 TiDB 后所计算的表的[校验和](#checksum)。 + + + +## S + +### Scattering + +指随机再分配 [Region](/v3.0/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 + +### Splitting + +指 TiKV Importer 在上传之前会将单个引擎文件拆分为若干小 [SST 文件](#sst-file)的操作。这是因为引擎文件通常很大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/v3.0/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 + +### SST file + +Sorted string table file（排序字符串表文件）。SST 文件是一种在 RocksDB 中（因而也是 TiKV 中）键值对集合在本地的存储形式。 + +TiKV Importer 从关闭的[引擎](#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](#ingest) 到 TiKV store 中。 diff --git a/v3.1/TOC.md b/v3.1/TOC.md index 5aadf13899bc..0f0a036f2a0f 100644 --- a/v3.1/TOC.md +++ b/v3.1/TOC.md @@ -355,6 +355,7 @@ - [监控告警](/v3.1/reference/tools/tidb-lightning/monitor.md) - [故障诊断](/v3.1/how-to/troubleshoot/tidb-lightning.md) - [FAQ](/v3.1/faq/tidb-lightning.md) + - [术语表](/v3.1/reference/tools/tidb-lightning/glossary.md) - [sync-diff-inspector](/v3.1/reference/tools/sync-diff-inspector/overview.md) - [PD Control](/v3.1/reference/tools/pd-control.md) - [PD Recover](/v3.1/reference/tools/pd-recover.md) diff --git a/v3.1/reference/tools/tidb-lightning/glossary.md b/v3.1/reference/tools/tidb-lightning/glossary.md new file mode 100644 index 000000000000..43b4775bb859 --- /dev/null +++ b/v3.1/reference/tools/tidb-lightning/glossary.md @@ -0,0 +1,193 @@ +--- +title: TiDB Lightning 术语表 +summary: 了解 TiDB Lightning 相关的术语及定义。 +category: glossary +--- + +# TiDB Lightning 术语表 + +本术语表提供了 TiDB Lightning 相关的术语和定义，这些术语会出现在 TiDB Lightning 的日志、监控指标、配置和文档中。 + + + +## A + +### Analyze + +统计信息分析。指重建 TiDB 表中的统计信息，即运行 [`ANALYZE TABLE`](/v3.1/reference/sql/statements/analyze-table.md) 语句。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，统计信息不会自动更新，所以 TiDB Lightning 在导入后显式地分析每个表。如果不需要该操作，可以将 `post-restore.analyze` 设置为 `false`。 + +### `AUTO_INCREMENT_ID` + +用于为自增列分配默认值的自增 ID 计数器。每张表都有一个相关联的 `AUTO_INCREMENT_ID` 计数器。在 TiDB 中，该计数器还用于分配行 ID。 + +因为 TiDB Lightning 不通过 TiDB 导入数据，`AUTO_INCREMENT_ID` 计数器不会自动更新，所以 TiDB Lightning 显式地将 `AUTO_INCREMENT_ID` 改为一个有效值。即使表中没有自增列，这步仍是会执行。 + + + +## B + +### Backend + +也称作 Back end（后端），用于接受 TiDB Lightning 解析结果。 + +详情参阅 [TiDB Lightning TiDB-backend](/v3.1/reference/tools/tidb-lightning/tidb-backend.md)。 + +### Black-white list + +黑白名单配置列表。用于指定要导入、忽略哪些表和库。 + +详情参阅 [TiDB Lightning 表库过滤](/v3.1/reference/tools/tidb-lightning/table-filter.md)。 + + + +## C + +### Checkpoint + +断点。用于保证 TiDB Lightning 在导入数据时不断地将进度保存到本地文件或远程数据库中。这样即使进程崩溃，TiDB Lightning 也能从中间状态恢复。 + +详情参见 [TiDB Lightning 断点续传](/v3.1/reference/tools/tidb-lightning/checkpoints.md)。 + +### Checksum + +校验和。一种用于[验证导入数据正确性](/v3.1/faq/tidb-lightning.md#如何校验导入的数据的正确性)的方法。 + +在 TiDB Lightning 中，表的校验和是由 3 个数字组成的集合，由该表中每个键值对的内容计算得出。这些数字分别是： + +* 键值对的数量 +* 所有键值对的总长度 +* 每个键值对 [CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) 按位异或的结果 + +TiDB Lightning 通过比较每个表的[本地校验和](#local-checksum)和[远程校验和](#remote-checksum)来验证导入数据的正确性。如果有任一对校验和不匹配，导入进程就会停止。如果你需要跳过校验和检查，可以将 `post-restore.checksum` 设置为 `false` 。 + +遇到校验和不匹配的问题时，参考[故障排查](/v3.1/how-to/troubleshoot/tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)进行处理。 + +### Chunk + +指数据源中的单个文件。 + +### Compaction + +压缩。指将多个小 SST 文件合并为一个大 SST 文件并清理已删除的条目。TiDB Lightning 导入数据时，TiKV 在后台会自动压缩数据。 + +> **注意：** +> +> 出于遗留原因，你仍然可以将 TiDB Lightning 配置为在每次导入表时进行显式压缩，但是官方不推荐采用该操作，且该操作的相关设置默认是禁用的。 +> +> 技术细节参阅 [RocksDB 关于压缩的说明](https://github.com/facebook/rocksdb/wiki/Compaction)。 + + + +## D + +### Data engine + +数据引擎。用于对实际的行数据进行排序的[引擎](#engine)。 + +当一个表数据很多的时候，表的数据会被放置在多个数据引擎中以改善任务流水线并节省 TiKV Importer 的空间。默认条件下，每 100 GB 的 SQL 数据会打开一个新的数据引擎（可通过 `mydumper.batch-size` 配置项进行更改）。 + +TiDB Lightning 同时处理多个数据引擎（可通过 `lightning.table-concurrency` 配置项进行更改）。 + + + +## E + +### Engine + +引擎。在 TiKV Importer 中，一个引擎就是一个用于排序键值对的 RocksDB 实例。 + +TiDB Lightning 通过引擎将数据传送到 TiKV Importer 中。Lightning 先打开一个引擎，向其发送未排序的键值对，然后关闭引擎。随后，引擎会对收到的键值对进行排序操作。这些关闭的引擎可以进一步上传至 TiKV store 中为 [Ingest](#ingest) 做准备。 + +引擎使用 TiKV Importer 的 `import-dir` 作为临时存储，有时也会被称为引擎文件 (engine files)。 + +另见[数据引擎](#data-engine)和[索引引擎](#index-engine)。 + + + +## I + +### Import mode + +导入模式。指通过降低读取速度和减少空间使用，来优化 TiKV 写入的配置模式。 + +导入过程中，TiDB Lightning 自动在导入模式和[普通模式](#normal-mode)中来回切换。如果 TiKV 卡在导入模式，你可以使用 `tidb-lightning-ctl` [强制切换回普通模式](/v3.1/faq/tidb-lightning.md#为什么用过-tidb-lightning-之后tidb-集群变得又慢又耗-cpu)。 + +### Index engine + +索引引擎。用于对索引进行排序的[引擎](#engine)。 + +不管表中有多少索引，每张表都只对应**一个**索引引擎。 + +TiDB Lightning 可同时处理多个索引引擎（可通过 `lightning.index-concurrency` 配置项进行更改）。由于每张表正好对应一个索引引擎，`lightning.index-concurrency` 配置项也限定了可同时处理的表的最大数量。 + +### Ingest + +指将 [SST 文件](#sst-file)的全部内容插入到 RocksDB（TiKV）store 中的操作。 + +与逐个插入键值对相比，Ingest 的效率非常高。因此，该操作直接决定了 TiDB Lightning 的性能。 + +技术细节参阅 [RocksDB 关于创建、Ingest SST 文件的 wiki 页面](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)。 + + + +## K + +### KV pair + +即 key-value pair（键值对）。 + +### KV encoder + +用于将 SQL 或 CSV 行解析为键值对的例程。多个 KV encoder 会并行运行以加快处理速度。 + + + +## L + +### Local checksum + +本地校验和。在将键值对发送到 TiKV Importer 前，由 TiDB Lightning 计算的表的校验和。 + + + +## N + +### Normal mode + +普通模式。未启用[导入模式](#import-mode)时的模式。 + + + +## P + +### Post-processing + +指整个数据源被解析发送到 TiKV Importer 之后的一段时间。此时 TiDB Lightning 正在等待 TiKV Importer 上传、[Ingest](#ingest) [SST 文件](#sst-file)。 + + + +## R + +### Remote checksum + +远程校验和。指导入 TiDB 后所计算的表的[校验和](#checksum)。 + + + +## S + +### Scattering + +指随机再分配 [Region](/v3.1/glossary.md#regionpeerraft-group) 中 leader 和 peer 的操作。Scattering 确保导入的数据在 TiKV store 中均匀分布，这样可以降低 PD 调度的压力。 + +### Splitting + +指 TiKV Importer 在上传之前会将单个引擎文件拆分为若干小 [SST 文件](#sst-file)的操作。这是因为引擎文件通常很大（约为 100 GB），在 TiKV 中不适合视为单一的 [Region](/v3.1/glossary.md#regionpeerraft-group)。拆分的文件大小可通过 `import.region-split-size` 配置项更改。 + +### SST file + +Sorted string table file（排序字符串表文件）。SST 文件是一种在 RocksDB 中（因而也是 TiKV 中）键值对集合在本地的存储形式。 + +TiKV Importer 从关闭的[引擎](#engine)中生成 SST 文件。这些 SST 文件接着被上传、[ingest](#ingest) 到 TiKV store 中。