diff --git a/alert-rules.md b/alert-rules.md index 7f7dc526365c..b03213b4ad3a 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -435,7 +435,7 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] * 处理方法： - 1. 执行 `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME="tikv_gc_leader_desc"` 来找到 gc leader 对应的 `tidb-server`； + 1. 执行 `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME="tikv_gc_leader_desc"` 来找到 gc leader 对应的 `tidb-server`； 2. 查看该 `tidb-server` 的日志，grep gc_worker tidb.log； 3. 如果发现这段时间一直在 resolve locks（最后一条日志是 `start resolve locks`）或者 delete ranges（最后一条日志是 `start delete {number} ranges`），说明 GC 进程是正常的。否则需要报备开发人员 [support@pingcap.com](mailto:support@pingcap.com) 进行处理。 @@ -604,25 +604,6 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/'] Apply Raft log 线程压力太大，通常是因为写入太猛了。 -#### `TiDB_tikvclient_gc_action_fail`（基本不发生，只在特殊配置下才会发生） - -* 报警规则： - - `sum(increase(tidb_tikvclient_gc_action_result{type="fail”}[1m])) > 10` - - > **注意：** - > - > 由于 3.0 中引入了分布式 GC 且 GC 不会在 TiDB 执行，因此 `tidb_tikvclient_gc_action_result` 指标虽然在 3.* 以上版本中存在，但是不会有值。 - -* 规则描述： - - GC 失败的 Region 较多。 - -* 处理方法： - - 1. 一般是因为并行 GC 开的太高了，可以适当降低 GC 并行度。你需要先确认 GC 失败是由于服务器繁忙导致的。 - 2. 通过执行 `update set VARIABLE_VALUE=”{number}” where VARIABLE_NAME=”tikv_gc_concurrency”` 适当降低并行度。 - ### 警告级别报警项 #### `TiKV_leader_drops` diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index 7f394fb61cc3..d6abd69f06a3 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -56,22 +56,22 @@ Could not read data from testSchema.testTable: GC life time is shorter than tran {{< copyable "sql" >}} ```sql - SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + SHOW GLOBAL VARIABLES LIKE 'tidb_gc_life_time'; ``` ```sql - +-----------------------+------------------------------------------------------------------------------------------------+ - | VARIABLE_NAME | VARIABLE_VALUE | - +-----------------------+------------------------------------------------------------------------------------------------+ - | tikv_gc_life_time | 10m0s | - +-----------------------+------------------------------------------------------------------------------------------------+ - 1 rows in set (0.02 sec) + +-------------------+-------+ + | Variable_name | Value | + +-------------------+-------+ + | tidb_gc_life_time | 10m0s | + +-------------------+-------+ + 1 row in set (0.03 sec) ``` {{< copyable "sql" >}} ```sql - UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + SET GLOBAL tidb_gc_life_time = '720h'; ``` 2. 执行 `dumpling` 命令后，将 TiDB 集群的 GC 值恢复到第 1 步中的初始值： @@ -79,7 +79,7 @@ Could not read data from testSchema.testTable: GC life time is shorter than tran {{< copyable "sql" >}} ```sql - UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; + SET GLOBAL tidb_gc_life_time = '10m'; ``` ## 向 TiDB 恢复数据 diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index 7212c5391208..6c8b77fc70c0 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-tool/','/docs-cn/dev/reference/too # 备份与恢复工具 BR 简介 -[BR](https://github.com/pingcap/br) 全称为 Backup & Restore，是 TiDB **分布式备份恢复**的命令行工具，用于对 TiDB 集群进行数据备份和恢复。**BR 只支持在 TiDB v3.1 及以上版本使用。** +[BR](https://github.com/pingcap/br) 全称为 Backup & Restore，是 TiDB **分布式备份恢复**的命令行工具，用于对 TiDB 集群进行数据备份和恢复。 相比 [`dumpling`](/backup-and-restore-using-dumpling-lightning.md)，BR 更适合**大数据量**的场景。 @@ -50,21 +50,15 @@ SST 文件以 `storeID_regionID_regionEpoch_keyHash_cf` 的格式命名。格式 > **注意：** > > - 如果没有挂载网盘或者使用其他共享存储，那么 BR 备份的数据会生成在各个 TiKV 节点上。由于 BR 只备份 leader 副本，所以各个节点预留的空间需要根据 leader size 来预估。 -> - 同时由于 v4.0 默认使用 leader count 进行平衡，所以会出现 leader size 差别大的问题，导致各个节点备份数据不均衡。 +> - 同时由于 TiDB 默认使用 leader count 进行平衡，所以会出现 leader size 差别大的问题，导致各个节点备份数据不均衡。 ### 使用限制 下面是使用 BR 进行备份恢复的几条限制： -- BR 只支持在 TiDB v3.1 及以上版本使用。 - BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。 - BR 只支持在 `new_collations_enabled_on_first_bootstrap` [开关值](/character-set-and-collation.md#排序规则支持)相同的集群之间进行操作。这是因为 BR 仅备份 KV 数据。如果备份集群和恢复集群采用不同的排序规则，数据校验会不通过。所以恢复集群时，你需要确保 `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';` 语句的开关值查询结果与备份时的查询结果相一致，才可以进行恢复。 - - 对于 v3.1 集群，TiDB 尚未支持 new collation，因此可以认为 new collation 未打开 - - 对于 v4.0 集群，请通过 `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled';` 查看 new collation 是否打开。 - - 例如，数据备份在 v3.1 集群。如果恢复到 v4.0 集群中，查询恢复集群的 `new_collation_enabled` 的值为 `true`，则说明创建恢复集群时打开了 new collation 支持的开关。此时恢复数据，可能会出错。 - ## 兼容性 BR 和 TiDB 集群的兼容性问题分为以下两方面： @@ -122,18 +116,11 @@ BR 内置版本会在执行备份和恢复操作前，对 TiDB 集群版本和 #### 通过 SQL 语句 -在 v4.0.2 及以上版本的 TiDB 中，支持直接通过 SQL 语句进行备份恢复，具体使用示例见： - -- [Backup 语法](/sql-statements/sql-statement-backup.md#backup) -- [Restore 语法](/sql-statements/sql-statement-restore.md#restore) +TiDB 支持使用 SQL 语句 [`BACKUP`](/sql-statements/sql-statement-backup.md#backup) 和 [`RESTORE`](/sql-statements/sql-statement-restore.md#restore) 进行备份恢复。如果要查看备份恢复的进度，你可以使用 [`SHOW BACKUPS|RESTORES`](/sql-statements/sql-statement-show-backups.md) 语句。 #### 通过命令行工具 -在 v3.1 以上的 TiDB 版本中，支持通过命令行工具进行备份恢复。 - -首先需要下载一个 BR 工具的二进制包，详见[下载链接](/download-ecosystem-tools.md#备份和恢复-br-工具)。 - -通过命令行工具进行备份恢复的具体操作见[使用备份与恢复工具 BR](/br/use-br-command-line-tool.md)。 +TiDB 支持使用 BR 命令行工具进行备份恢复（需[手动下载](/download-ecosystem-tools.md#备份和恢复-br-工具)）。关于 BR 命令行工具的具体使用方法，请参阅[使用备份与恢复工具 BR](/br/use-br-command-line-tool.md)。 #### 在 Kubernetes 环境下 diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index cbba254be900..056d63bbf607 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -78,26 +78,12 @@ BR 可以直接将命令下发到 TiKV 集群来执行备份和恢复，不依 ### 备份前的准备工作 -如果你使用的是 TiDB v4.0.8 及以上版本，相应版本的 BR 工具已支持自适应 GC。你只需要将 `backupTS` 注册到 PD 的 `safePoint`，保证 `safePoint` 在备份期间不会向前移动，即可避免手动设置 GC。 +关于 `br backup` 命令的具体使用方法，参见[使用备份与恢复工具 BR](/br/use-br-command-line-tool.md)。 -如果你使用的是 TiDB v4.0.7 及以下版本，则需要在 BR 备份前后，按照以下步骤手动设置 GC： +运行 `br backup` 命令前，请确保以下条件： -1. 运行 [`br backup` 命令](/br/use-br-command-line-tool.md#br-命令行描述)前，查询 TiDB 集群的 [`tikv_gc_life_time`](/garbage-collection-configuration.md#tikv_gc_life_time) 配置项的值，并使用 MySQL 客户端将该项调整至合适的值，确保备份期间不会发生 [Garbage Collection](/garbage-collection-overview.md) (GC)。 - - {{< copyable "sql" >}} - - ```sql - SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - ``` - -2. 在备份完成后，将该参数调回原来的值。 - - {{< copyable "sql" >}} - - ```sql - UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time'; - ``` +1. TiDB 集群中没有正在运行中的 DDL。 +2. 用于创建备份的存储设备有足够的空间。 ### 恢复前的准备工作 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index 306aff691f34..d8a12f1f7b23 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -63,19 +63,6 @@ BR 由多层命令组成。目前，BR 包含 `backup`、`restore` 和 `version` 使用 `br backup` 命令来备份集群数据。可选择添加 `full` 或 `table` 子命令来指定备份的范围：全部集群数据或单张表的数据。 -如果 BR 的版本低于 v4.0.8，而且备份时间可能超过设定的 [`tikv_gc_life_time`](/garbage-collection-configuration.md#tikv_gc_life_time)（默认 `10m0s`，即表示 10 分钟），需要手动将该参数调大。 - -例如，将 `tikv_gc_life_time` 调整为 `720h`： - -{{< copyable "sql" >}} - -```sql -mysql -h${TiDBIP} -P4000 -u${TIDB_USER} ${password_str} -Nse \ - "update mysql.tidb set variable_value='720h' where variable_name='tikv_gc_life_time'"; -``` - -自 v4.0.8 起 BR 已经支持自适应 GC，无需手动调整 `tikv_gc_life_time`。 - ### 备份全部集群数据 要备份全部集群数据，可使用 `br backup full` 命令。该命令的使用帮助可以通过 `br backup full -h` 或 `br backup full --help` 来获取。 diff --git a/dumpling-overview.md b/dumpling-overview.md index 41ad4fa8a450..923413cd3fe7 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -303,7 +303,7 @@ Dumpling 导出 TiDB 较大单表时，可能会因为导出数据过大导致 T {{< copyable "sql" >}} ```sql -update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time'; +SET GLOBAL tidb_gc_life_time = '720h'; ``` 在操作结束之后，再将 GC 时间调回原样（默认是 `10m`）： @@ -311,7 +311,7 @@ update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_lif {{< copyable "sql" >}} ```sql -update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time'; +SET GLOBAL tidb_gc_life_time = '10m'; ``` 最后，所有的导出数据都可以用 [TiDB Lightning](/tidb-lightning/tidb-lightning-backends.md) 导入回 TiDB。 diff --git a/error-codes.md b/error-codes.md index 12e7603d861b..5ed808d851b9 100644 --- a/error-codes.md +++ b/error-codes.md @@ -119,7 +119,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 * Error Number: 8048 - 设置了不支持的隔离级别，如果是使用第三方工具或框架等无法修改代码进行适配的情况，可以考虑通过 `tidb_skip_isolation_level_check` 来绕过这一检查。 + 设置了不支持的隔离级别，如果是使用第三方工具或框架等无法修改代码进行适配的情况，可以考虑通过 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check) 来绕过这一检查。 {{< copyable "sql" >}} @@ -141,13 +141,9 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 * Error Number: 8055 - 当前快照过旧，数据可能已经被 GC。可以调大 `tikv_gc_life_time` 的值来避免该问题。新版本的 TiDB 会自动为长时间运行的事务保留数据，一般不会遇到该错误。有关 GC 的介绍和配置可以参考 [GC 机制简介](/garbage-collection-overview.md)和 [GC 配置](/garbage-collection-configuration.md)文档。 - - {{< copyable "sql" >}} - - ```sql - update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time"; - ``` + 当前快照过旧，数据可能已经被 GC。可以调大 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) 的值来避免该问题。从 TiDB v4.0.8 版本起， TiDB 会自动为长时间运行的事务保留数据，一般不会遇到该错误。 + + 有关 GC 的介绍和配置可以参考 [GC 机制简介](/garbage-collection-overview.md)和 [GC 配置](/garbage-collection-configuration.md)文档。 * Error Number: 8059 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 4c5127a70a39..3c22905fc681 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -18,7 +18,10 @@ TiDB 支持绝大多数 MySQL 语法，一般不需要修改代码。 ### 如何导出 TiDB 数据？ -TiDB 目前暂时不支持 `select into outfile`，可以通过以下方式导出 TiDB 数据：参考 [MySQL 使用 mysqldump 导出某个表的部分数据](https://blog.csdn.net/xin_yu_xin/article/details/7574662)，使用 mysqldump 加 where 条件导出，使用 MySQL client 将 select 的结果输出到一个文件。 +你可以通过以下方式导出 TiDB 数据： + +- 参考 [MySQL 使用 mysqldump 导出某个表的部分数据](https://blog.csdn.net/xin_yu_xin/article/details/7574662)，使用 mysqldump 加 where 条件导出。 +- 使用 MySQL client 将 select 的结果输出到一个文件。 ### 如何从 DB2、Oracle 数据库迁移到 TiDB？ @@ -117,7 +120,3 @@ DELETE，TRUNCATE 和 DROP 都不会立即释放空间。对于 TRUNCATE 和 DRO - 目前已开发分布式导入工具 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)，需要注意的是数据导入过程中为了性能考虑，不会执行完整的事务流程，所以没办法保证导入过程中正在导入的数据的 ACID 约束，只能保证整个导入过程结束以后导入数据的 ACID 约束。因此适用场景主要为新数据的导入（比如新的表或者新的索引），或者是全量的备份恢复（先 Truncate 原表再导入）。 - TiDB 的数据加载与磁盘以及整体集群状态相关，加载数据时应关注该主机的磁盘利用率，TiClient Error/Backoff/Thread CPU 等相关 metric，可以分析相应瓶颈。 - -### 对数据做删除操作之后，空间回收比较慢，如何处理？ - -可以设置并行 GC，加快对空间的回收速度。默认并发为 1，最大可调整为 tikv 实例数量的 50%。可使用 `update mysql.tidb set VARIABLE_VALUE="3" where VARIABLE_NAME="tikv_gc_concurrency";` 命令来调整。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index e041455e3138..2a17456f0f55 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -131,7 +131,7 @@ DELETE，TRUNCATE 和 DROP 都不会立即释放空间。对于 TRUNCATE 和 DRO ## 对数据做删除操作之后，空间回收比较慢，如何处理？ -可以设置并行 GC，加快对空间的回收速度。默认并发为 1，最大可调整为 TiKV 实例数量的 50%。可使用 `update mysql.tidb set VARIABLE_VALUE="3" where VARIABLE_NAME="tikv_gc_concurrency";` 命令来调整。 +TiDB 采用了多版本并发控制 (MVCC)，为了使并发事务能查看到早期版本的数据，删除数据不会立即回收空间，而是推迟一段时间后再进行垃圾回收 (GC)。你可以通过修改系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 )的值（默认值为 `10m0s`）配置历史数据的保留时限。 ## `SHOW PROCESSLIST` 是否显示系统进程号？ diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index d43e327a852c..59b698beae8f 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -127,12 +127,12 @@ TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV #### 3.1.7 ERROR 9006 (HY000) : GC life time is shorter than transaction duration -`GC Life Time` 间隔时间过短，长事务本应读到的数据可能被清理了，可使用如下命令增加 `GC Life Time`： +`GC Life Time` 间隔时间过短，长事务本应读到的数据可能被清理了。你可以使用如下命令修改 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) 的值： {{< copyable "sql" >}} ```sql -update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time'; +SET GLOBAL tidb_gc_life_time = '30m'; ``` 其中 30m 代表仅清理 30 分钟前的数据，这可能会额外占用一定的存储空间。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index 7adc6e56f7e2..285c6a638668 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -5,137 +5,17 @@ aliases: ['/docs-cn/dev/garbage-collection-configuration/','/docs-cn/dev/referen # GC 配置 -TiDB 的 GC 相关的配置存储于 `mysql.tidb` 系统表中，可以通过 SQL 语句对这些参数进行查询和更改： +你可以通过以下系统变量进行 GC 配置: -{{< copyable "sql" >}} - -```sql -select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like "tikv_gc%"; -``` - -``` -+--------------------------+----------------------------------------------------------------------------------------------------+ -| VARIABLE_NAME | VARIABLE_VALUE | -+--------------------------+----------------------------------------------------------------------------------------------------+ -| tikv_gc_leader_uuid | 5afd54a0ea40005 | -| tikv_gc_leader_desc | host:tidb-cluster-tidb-0, pid:215, start at 2019-07-15 11:09:14.029668932 +0000 UTC m=+0.463731223 | -| tikv_gc_leader_lease | 20190715-12:12:14 +0000 | -| tikv_gc_enable | true | -| tikv_gc_run_interval | 10m0s | -| tikv_gc_life_time | 10m0s | -| tikv_gc_last_run_time | 20190715-12:09:14 +0000 | -| tikv_gc_safe_point | 20190715-11:59:14 +0000 | -| tikv_gc_auto_concurrency | true | -| tikv_gc_mode | distributed | -+--------------------------+----------------------------------------------------------------------------------------------------+ -13 rows in set (0.00 sec) -``` - -例如，如果需要将 GC 调整为保留最近一天以内的数据，只需执行下列语句即可： - -{{< copyable "sql" >}} - -```sql -update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time"; -``` - -> **注意：** -> -> `mysql.tidb` 系统表中除了下文列出的 GC 的配置以外，还包含一些 TiDB 用于储存部分集群状态（包括 GC 状态）的记录。请勿手动更改这些记录。其中，与 GC 有关的记录如下： -> -> - `tikv_gc_leader_uuid`，`tikv_gc_leader_desc` 和 `tikv_gc_leader_lease` 用于记录 GC leader 的状态 -> - `tikv_gc_last_run_time`：最近一次 GC 运行的时间（每轮 GC 开始时更新） -> - `tikv_gc_safe_point`：当前的 safe point （每轮 GC 开始时更新） - -## `tikv_gc_enable` - -- 控制是否启用 GC。 -- 默认值：`true` - -## `tikv_gc_run_interval` - -- 指定 GC 运行时间间隔。Duration 类型，使用 Go 的 Duration 字符串格式，如 `"1h30m"`，`"15m"` 等。 -- 默认值：`"10m0s"` - -## `tikv_gc_life_time` - -- 每次 GC 时，保留数据的时限。Duration 类型。每次 GC 时将以当前时间减去该配置的值作为 safe point。 -- 默认值：`"10m0s"` - -> **注意：** -> -> - 在数据更新频繁的场景下，如果将 `tikv_gc_life_time` 设置得比较大（如数天甚至数月），可能会有一些潜在的问题，如： -> - 磁盘空间占用较多。 -> - 大量的历史版本会在一定程度上影响性能，尤其是范围查询（如 `select count(*) from t`）。 -> - 如果存在运行时间很长、超过了 `tikv_gc_life_time` 的事务，那么在 GC 时，会保留自该事务的开始时间 (start_ts) 以来的数据，以允许该事务继续运行。例如，如果 `tikv_gc_life_time` 配置为 10 分钟，而某次 GC 时，集群中正在运行的事务中开始时间最早的一个事务已经运行了 15 分钟，那么本次 GC 便会保留最近 15 分钟的数据。 - -## `tikv_gc_mode` - -指定 GC 模式。可选值如下： - -- `"distributed"`（默认）：分布式 GC 模式。在此模式下，[Do GC](/garbage-collection-overview.md#do-gc进行-gc-清理) 阶段由 TiDB 上的 GC leader 向 PD 发送 safe point，每个 TiKV 节点各自获取该 safe point 并对所有当前节点上作为 leader 的 Region 进行 GC。此模式于 TiDB 3.0 引入。 - -- `"central"`：集中 GC 模式。在此模式下，[Do GC](/garbage-collection-overview.md#do-gc进行-gc-清理) 阶段由 GC leader 向所有的 Region 发送 GC 请求。TiDB 2.1 及更早版本采用此 GC 模式。从 TiDB 5.0 起不再支持该模式，设置该模式的集群将切换到 `distributed` 模式。 - -## `tikv_gc_auto_concurrency` - -控制是否由 TiDB 自动决定 GC concurrency，即同时进行 GC 的线程数。 - -当 `tikv_gc_mode` 设为 `"distributed"`，GC concurrency 将应用于 [Resolve Locks](/garbage-collection-overview.md#resolve-locks清理锁) 阶段。当 [`tikv_gc_mode`](#tikv_gc_mode) 设为 `"central"` 时，GC concurrency 将应用于 Resolve Locks 以及 [Do GC](/garbage-collection-overview.md#do-gc进行-gc-清理) 两个阶段。 - -- `true`（默认）：自动以 TiKV 节点的个数作为 GC concurrency -- `false`：使用 [`tikv_gc_concurrency`](#tikv_gc_concurrency) 的值作为 GC 并发数 - -## `tikv_gc_concurrency` - -- 手动设置 GC concurrency。要使用该参数，必须将 [`tikv_gc_auto_concurrency`](#tikv_gc_auto_concurrency) 设为 `false` 。 -- 默认值：2 - -## `tikv_gc_scan_lock_mode` - -> **警告：** -> -> Green GC 目前是实验性功能，不建议在生产环境中使用。 - -设定 GC 的 Resolve Locks 阶段中，扫描锁的方式，即是否开启 Green GC（实验性特性）。Resolve Locks 阶段需要扫描整个集群的锁。在不开启 Green GC 的情况下，TiDB 会以 Region 为单位进行扫描。Green GC 提供了“物理扫描”的功能，即每台 TiKV 节点分别绕过 Raft 层直接扫描数据。该功能可以有效缓解 [Hibernate Region](/tikv-configuration-file.md#hibernate-regions-实验特性) 功能开启时，GC 唤醒全部 Region 的现象，并一定程度上提升 Resolve Locks 阶段的执行速度。 - -- `"legacy"`（默认）：使用旧的扫描方式，即关闭 Green GC。 -- `"physical"`：使用物理扫描的方式，即开启 Green GC。 - -> **注意：** -> -> 该项配置是隐藏配置。首次开启需要执行： -> -> {{< copyable "sql" >}} -> -> ```sql -> insert into mysql.tidb values ('tikv_gc_scan_lock_mode', 'legacy', ''); -> ``` - -## 关于 GC 流程的说明 - -从 TiDB 3.0 版本起，由于对分布式 GC 模式和并行 Resolve Locks 的支持，部分配置选项的作用发生了变化。可根据下表理解不同版本中这些配置的区别： - -| 版本/配置 | Resolve Locks | Do GC | -|-------------------|---------------|----------------| -| 2.x | 串行 | 并行 | -| 3.0
`tikv_gc_mode = centered`
`tikv_gc_auto_concurrency = false` | 并行 | 并行 | -| 3.0
`tikv_gc_mode = centered`
`tikv_gc_auto_concurrency = true` | 自动并行 | 自动并行 | -| 3.0
`tikv_gc_mode = distributed`
`tikv_gc_auto_concurrency = false` | 并行 | 分布式 | -| 3.0
`tikv_gc_mode = distributed`
`tikv_gc_auto_concurrency = true`
（默认配置） | 自动并行 | 分布式 | - -表格内容说明： - -- 串行：由 TiDB 逐个向 Region 发送请求。 -- 并行：使用 `tikv_gc_concurrency` 选项所指定的线程数，并行地向每个 Region 发送请求。 -- 自动并行：使用 TiKV 节点的个数作为线程数，并行地向每个 Region 发送请求。 -- 分布式：无需 TiDB 通过对 TiKV 发送请求的方式来驱动，而是每台 TiKV 自行工作。 - -另外，如果 Green GC （实验特性）开启（即 [`tikv_gc_scan_lock_mode`](#tikv_gc_scan_lock_mode) 配置项设为 `"physical"`），Resolve Lock 的执行将不受上述并行配置的影响。 +* [`tidb_gc_enable`](/system-variables.md#tidb_gc_enable-从-v50-ga-版本开始引入 ) +* [`tidb_gc_run_interval`](/system-variables.md#tidb_gc_run_interval-从-v50-ga-版本开始引入 ) +* [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) +* [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-从-v50-ga-版本开始引入 ) +* [`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-从-v50-ga-版本开始引入 ) ## 流控 -TiDB 在 3.0.6 版本开始支持 GC 流控，可通过配置 `gc.max-write-bytes-per-sec` 限制 GC worker 每秒数据写入量，降低对正常请求的影响，`0` 为关闭该功能。该配置可通过 tikv-ctl 动态修改： +TiDB 支持 GC 流控，可通过配置 `gc.max-write-bytes-per-sec` 限制 GC worker 每秒数据写入量，降低对正常请求的影响，`0` 为关闭该功能。该配置可通过 tikv-ctl 动态修改： {{< copyable "shell-regular" >}} @@ -143,9 +23,17 @@ TiDB 在 3.0.6 版本开始支持 GC 流控，可通过配置 `gc.max-write-byte tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB ``` +## TiDB 5.0 引入的变化 + +在 TiDB 5.0 之前的版本中，GC 是通过系统表 `mysql.tidb` 进行配置的。从 TiDB 5.0 版本起，GC 仍然可以通过系统表 `mysql.tidb` 进行配置，但建议你使用系统变量进行配置，这样可以确保对配置的任何更改都能得到验证，防止造成异常行为 ([#20655](https://github.com/pingcap/tidb/issues/20655))。 + +TiDB 5.0 及之后的版本不再需要向各个 TiKV Region 都发送触发 GC 的请求，因此不再提供 `CENTRAL` GC 模式的支持，取而代之的是效率更高的 `DISTRIBUTED` GC 模式 （自 TiDB 3.0 起的默认 GC 模式）。 + +如果要了解 TiDB 历史版本中 GC 配置的变化信息，请使用左侧导航栏中的 _TIDB 版本选择器_ 切换到本文档的历史版本。 + ## GC in Compaction Filter 机制 -GC in Compaction Filter 机制是在分布式 GC 模式 (distributed GC) 的基础上，由 RocksDB 的 Compaction 过程来进行 GC，而不再使用一个单独的 GC worker 线程。这样做的好处是避免了 GC 引起的额外磁盘读取，以及避免清理掉的旧版本残留大量删除标记影响顺序扫描性能。可以由 TiKV 配置文件中的以下开关控制： +GC in Compaction Filter 机制是在分布式 GC 模式 (`DISTRIBUTED` GC mode) 的基础上，由 RocksDB 的 Compaction 过程来进行 GC，而不再使用一个单独的 GC worker 线程。这样做的好处是避免了 GC 引起的额外磁盘读取，以及避免清理掉的旧版本残留大量删除标记影响顺序扫描性能。可以由 TiKV 配置文件中的以下开关控制： {{< copyable "" >}} diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index 35afe43c8590..a36eaacef139 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -27,7 +27,16 @@ TiDB 的事务是基于 [Google Percolator](https://ai.google/research/pubs/pub3 Resolve Locks 这一步的任务即对 safe point 之前的锁进行清理。即如果一个锁对应的 Primary 已经提交，那么该锁也应该被提交；反之，则应该回滚。而如果 Primary 仍然是上锁的状态（没有提交也没有回滚），则应当将该事务视为超时失败而回滚。 -Resolve Locks 的执行方式是由 GC leader 对所有的 Region 发送请求扫描过期的锁，并对扫到的锁查询 Primary 的状态，再发送请求对其进行提交或回滚。这个过程默认会并行地执行，并发数量默认与 TiKV 节点个数相同。 +Resolve Locks 有两种执行模式： + +- `LEGACY` （默认模式）：由 GC leader 对所有的 Region 发送请求扫描过期的锁，并对扫到的锁查询 Primary 的状态，再发送请求对其进行提交或回滚。 +- `PHYSICAL`：TiDB 绕过 Raft 层直接扫描每个 TiKV 节点上的数据。 + +> **警告：** +> +> `PHYSICAL`模式（即启用 Green GC）目前是实验性功能，不建议在生产环境中使用。 + +你可以通过修改系统变量 [`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-从-v50-ga-版本开始引入 ) 的值切换 Resolve Locks 的执行模式。 ### Delete Ranges（删除区间） @@ -41,4 +50,4 @@ Resolve Locks 的执行方式是由 GC leader 对所有的 Region 发送请求 > **注意：** > -> TiDB v2.1 以及更早的版本中，Do GC 这一步是通过由 TiDB 对每个 Region 发送请求的方式实现的。在 v3.0 及更新的版本中，通过修改配置可以继续使用旧的 GC 方式，详情请参考 [GC 配置](/garbage-collection-configuration.md#tikv_gc_mode)。 +> 从 TiDB 5.0 版本起，`CENTRAL` GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已经废弃， Do GC 这一步将只以 `DISTRIBUTED` GC 模式（从 TiDB 3.0 版起的默认模式）运行。 diff --git a/partitioned-table.md b/partitioned-table.md index d0fdab9ca017..bc8b1fd47127 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -1237,4 +1237,4 @@ select * from t; 环境变量 `tidb_enable_list_partition` 可以控制是否启用分区表功能。如果该变量设置为 `OFF`，则建表时会忽略分区信息，以普通表的方式建表。 -该变量仅作用于建表，已经建表之后再修改该变量无效。详见[系统变量和语法](/system-variables.md#tidb_enable_list_partition-从-v50-ga-版本开始引入)。 +该变量仅作用于建表，已经建表之后再修改该变量无效。详见[系统变量和语法](/system-variables.md#tidb_enable_list_partition-从-v50-ga-版本开始引入 )。 diff --git a/read-historical-data.md b/read-historical-data.md index e294f7e901f4..5773efe9efd6 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -15,13 +15,18 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 ## 操作流程 -为支持读取历史版本数据， 引入了一个新的 system variable: tidb_snapshot ，这个变量是 Session 范围有效，可以通过标准的 Set 语句修改其值。其值为文本，能够存储 TSO 和日期时间。TSO 即是全局授时的时间戳，是从 PD 端获取的; 日期时间的格式可以为：“2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。当这个变量被设置时，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 Select 操作都会在这个 Snapshot 上读取数据。 +为支持读取历史版本数据， TiDB 引入了一个新的系统变量 [`tidb_snapshot`](/system-variables.md#tidb_snapshot)： + +- 这个变量的作用域为 `SESSION`。 +- 你可以通过标准的 `SET` 语句修改这个变量的值。 +- 这个变量的数据类型为文本类型，能够存储 TSO 和日期时间。TSO 是从 PD 端获取的全局授时的时间戳，日期时间的格式为：“2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 +- 当这个变量被设置时，TiDB 会按照设置的时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 `SELECT` 操作都会从这个 Snapshot 上读取数据。 > **注意：** > > TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。 -当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。 +当读取历史版本操作结束后，可以结束当前 Session 或者是通过 `SET` 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。 ## 历史数据保留策略 @@ -29,7 +34,10 @@ TiDB 使用 MVCC 管理版本，当更新/删除数据时，不会做真正的 TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 [TiDB 垃圾回收 (GC)](/garbage-collection-overview.md)。 -这里需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。`tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改；`tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。 +这里需要重点关注的是： + +- 使用系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) 可以配置历史版本的保留时间（默认值是 `10m0s`）。 +- 使用 SQL 语句 `SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point'` 可以查询当前的 safePoint，即当前可以读的最旧的快照。在每次 GC 开始运行时，safePoint 将自动更新。 ## 示例 diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index 05afc2aff5ab..302624cb9f14 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -7,14 +7,16 @@ aliases: ['/docs-cn/dev/sql-statements/sql-statement-flashback-table/','/docs-cn 在 TiDB 4.0 中，引入了 `FLASHBACK TABLE` 语法，其功能是在 Garbage Collection (GC) life time 时间内，可以用 `FLASHBACK TABLE` 语句来恢复被 `DROP` 或 `TRUNCATE` 删除的表以及数据。 -查询集群的 `tikv_gc_safe_point` 和 `tikv_gc_life_time`。只要被 `DROP` 或 `TRUNCATE` 删除的表是在 `tikv_gc_safe_point` 时间之后，都能用 `FLASHBACK TABLE` 语法来恢复。 +可以使用系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) 配置数据的历史版本的保留时间（默认值是 `10m0s`）。可以使用以下 SQL 语句查询当前的 `safePoint`， 即 GC 已经清理到的时间点： {{< copyable "sql" >}} ```sql - select * from mysql.tidb where variable_name in ('tikv_gc_safe_point','tikv_gc_life_time'); + SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point'; ``` +只要被 `DROP` 或 `TRUNCATE` 删除的表是在 `tikv_gc_safe_point` 时间之后，都能用 `FLASHBACK TABLE` 语法来恢复。 + ## 语法 {{< copyable "sql" >}} diff --git a/system-variables.md b/system-variables.md index 11fbe9a0a68e..f19a934d761b 100644 --- a/system-variables.md +++ b/system-variables.md @@ -620,6 +620,50 @@ v5.0.0-rc 后，用户仍可以单独修改以上系统变量（会有废弃警 - 这个变量用于改变 TiDB server 上执行的语句的默认优先级。例如，你可以通过设置该变量来确保正在执行 OLAP 查询的用户优先级低于正在执行 OLTP 查询的用户。 - 可设置为 `NO_PRIORITY`、`LOW_PRIORITY`、`DELAYED` 或 `HIGH_PRIORITY`。 +### `tidb_gc_concurrency` 从 v5.0 GA 版本开始引入 + +- 作用域：GLOBAL +- 默认值：-1 +- 这个变量用于指定 GC 在[Resolve Locks（清理锁）](/garbage-collection-overview.md#resolve-locks清理锁)步骤中线程的数量。默认值 `-1` 表示由 TiDB 自主判断运行 GC 要使用的线程的数量。 + +### `tidb_gc_enable` 从 v5.0 GA 版本开始引入 + +- 作用域：GLOBAL +- 默认值：ON +- 这个变量用于控制是否启用 TiKV 的垃圾回收 (GC) 机制。如果不启用 GC 机制，系统将不再清理旧版本的数据，因此会有损系统性能。 + +### `tidb_gc_life_time` 从 v5.0 GA 版本开始引入 + +- 作用域：GLOBAL +- 默认值：`"10m0s"` +- 这个变量用于指定每次进行垃圾回收 (GC) 时保留数据的时限。变量值为 Go 的 Duration 字符串格式。每次进行 GC 时，将以当前时间减去该变量的值作为 safe point。 + +> **Note:** +> +> - 在数据频繁更新的场景下，将 `tidb_gc_life_time` 的值设置得过大（如数天甚至数月）可能会导致一些潜在的问题，如： +> - 占用更多的存储空间。 +> - 大量的历史数据可能会在一定程度上影响系统性能，尤其是范围的查询（如 `select count(*) from t`）。 +> - 如果一个事务的运行时长超过了 `tidb_gc_life_time` 配置的值，在 GC 时，为了使这个事务可以继续正常运行，系统会保留从这个事务开始时间 `start_ts` 以来的数据。例如，如果 `tidb_gc_life_time` 的值配置为 10 分钟，且在一次 GC 时，集群正在运行的事务中最早开始的那个事务已经运行了 15 分钟，那么本次 GC 将保留最近 15 分钟的数据。 + +### `tidb_gc_run_interval` 从 v5.0 GA 版本开始引入 + +- 作用域：GLOBAL +- 默认值：`"10m0s"` +- 这个变量用于指定垃圾回收 (GC) 运行的时间间隔。变量值为 Go 的 Duration 字符串格式，如`"1h30m"`、`"15m"`等。 + +### `tidb_gc_scan_lock_mode` 从 v5.0 GA 版本开始引入 + +> **警告：** +> +> Green GC 目前是实验性功能，不建议在生产环境中使用。 + +- 作用域：GLOBAL +- 默认值：`LEGACY` +- 可设置为： + - `LEGACY`：使用旧的扫描方式，即禁用 Green GC。 + - `PHYSICAL`：使用物理扫描方式，即启用 Green GC。 +- 这个变量用于指定垃圾回收 (GC) 的 Resolve Locks（清理锁）步骤中扫描锁的方式。当变量值设置为 `LEGACY` 时，TiDB 以 Region 为单位进行扫描。当变量值设置为 `PHYSICAL` 时，每个 TiKV 节点分别绕过 Raft 层直接扫描数据，可以有效地缓解在启用 [Hibernate Region](/tikv-configuration-file.md#hibernate-regions-实验特性) 功能时，GC 唤醒全部 Region 的影响，从而提升 Resolve Locks（清理锁）这个步骤的执行速度。 + ### `tidb_general_log` - 作用域：INSTANCE diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 64ac48521e61..b2791fd0339a 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -514,7 +514,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles ### 7.1 TiDB -- 7.1.1 `GC life time is shorter than transaction duration`。事务执行时间太长，超过了 GC lifetime（默认 10min），可以通过修改 `mysql.tidb` 表来调整 `life time`，通常情况下不建议修改，会导致大量老版本堆积起来（如果有大量 `update` 和 `delete` 语句）。 +- 7.1.1 `GC life time is shorter than transaction duration`。事务执行时间太长，超过了 GC lifetime（默认为 10 分钟），可以通过修改系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-ga-版本开始引入 ) 来延长 life time，通常情况下不建议修改，因为延长时限可能导致大量老版本数据的堆积（如果有大量 `UPDATE` 和 `DELETE` 语句）。 - 7.1.2 `txn takes too much time`。事务太长时间（超过 590s）没有提交，准备提交的时候报该错误。可以通过调大 `[tikv-client] max-txn-time-use = 590` 参数，以及调大 `GC life time` 来绕过该问题（如果确实有这个需求）。通常情况下，建议看看业务是否真的需要执行这么长时间的事务。 @@ -526,12 +526,10 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - `wait response is cancelled`。请求发送到 TiKV 后超时未收到 TiKV 响应。需要排查对应地址 TiKV 的响应时间和对应 Region 在当时的 PD 和 KV 日志，确定为什么 KV 未及时响应。 -- 7.1.5 distsql.go 报 `inconsistent index`。数据索引疑似发生不一致，首先对报错的信息中 index 所在表执行 `admin check table ` 命令，如果检查失败，则先通过命令关闭 GC，然后[报 bug](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 +- 7.1.5 distsql.go 报 `inconsistent index`。数据索引疑似发生不一致，首先对报错的信息中 index 所在表执行 `admin check table ` 命令，如果检查失败，则先通过以下命令禁用 GC，然后[报 bug](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 ```sql - begin; - update mysql.tidb set variable_value='72h' where variable_name='tikv_gc_life_time'; - commit; + SET GLOBAL tidb_gc_enable = 0; ``` ### 7.2 TiKV diff --git a/tiflash/use-tiflash.md b/tiflash/use-tiflash.md index d9ed3574b9be..8b0b1461b837 100644 --- a/tiflash/use-tiflash.md +++ b/tiflash/use-tiflash.md @@ -247,7 +247,7 @@ round without fraction, cast(int as decimal), date_add(datetime, int), date_add( ## 使用 MPP 模式 -TiFlash 支持 MPP 模式的查询执行，即在计算中引入跨节点的数据交换（data shuffle 过程）。MPP 模式默认开启，如需关闭可将全局/会话变量 [`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-从-v50-ga-版本开始引入) 的值设为 `0` 或 `OFF`： +TiFlash 支持 MPP 模式的查询执行，即在计算中引入跨节点的数据交换（data shuffle 过程）。MPP 模式默认开启，如需关闭可将全局/会话变量 [`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-从-v50-ga-版本开始引入 ) 的值设为 `0` 或 `OFF`： ```shell set @@session.tidb_allow_mpp=0 @@ -283,5 +283,5 @@ mysql> explain select count(*) from customer c join nation n on c.c_nationkey=n. TiFlash 提供了两个全局/会话变量决定是否选择 Broadcast Hash Join，分别为： -- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-ga-版本开始引入)，单位为 bytes。如果表大小（字节数）小于该值，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 -- [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-ga-版本开始引入)，单位为行数。如果 join 的对象为子查询，优化器无法估计子查询结果集大小，在这种情况下通过结果集行数判断。如果子查询的行数估计值小于该变量，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-ga-版本开始引入 )，单位为 bytes。如果表大小（字节数）小于该值，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。 +- [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-从-v50-ga-版本开始引入 )，单位为行数。如果 join 的对象为子查询，优化器无法估计子查询结果集大小，在这种情况下通过结果集行数判断。如果子查询的行数估计值小于该变量，则选择 Broadcast Hash Join 算法。否则选择 Shuffled Hash Join 算法。