diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 6cb71c853087..00347f6e209d 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -69,7 +69,7 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 从 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 +> 从 v8.5.5 和 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。 @@ -93,13 +93,13 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 为了兼容旧版本集群，从 v9.0.0 开始，当恢复集群不存在系统表 `mysql.tidb_pitr_id_map` 时，`pitr_id_map` 数据会写到日志备份目录下，文件名为 `pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`。 +> 为了兼容旧版本集群，从 v8.5.5 和 v9.0.0 开始，当恢复集群不存在系统表 `mysql.tidb_pitr_id_map` 时，`pitr_id_map` 数据会写到日志备份目录下，文件名为 `pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`。 ## 实现细节：将断点数据存储在外部存储 > **注意：** > -> 从 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。例如： +> 从 v8.5.5 和 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。例如： > > ```shell > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" @@ -159,4 +159,4 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 为了兼容旧版本集群，从 v9.0.0 开始，当恢复集群不存在系统表 `mysql.tidb_pitr_id_map` 且未指定参数 `--checkpoint-storage` 时，`pitr_id_map` 数据会写到日志备份目录下，文件名为 `pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`。 +> 为了兼容旧版本集群，从 v8.5.5 和 v9.0.0 开始，当恢复集群不存在系统表 `mysql.tidb_pitr_id_map` 且未指定参数 `--checkpoint-storage` 时，`pitr_id_map` 数据会写到日志备份目录下，文件名为 `pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`。 diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index d0a978607a68..762a5b9b1c7d 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -15,7 +15,7 @@ summary: 了解如何通过压缩日志备份为 SST 格式来提升按时间点 - 写放大：所有写入必须从 LSM Tree 的 L0 开始被逐级别 compact 到底层。 - 全量备份依赖：需频繁执行全量备份以控制恢复数据量，对业务有一定影响。 -从 v9.0.0 开始，压缩日志备份功能提供了离线压缩能力，可将日志备份的非结构化数据转换为结构化的 SST 文件，从而实现以下改进： +从 v8.5.5 和 v9.0.0 开始，压缩日志备份功能提供了离线压缩能力，可将日志备份的非结构化数据转换为结构化的 SST 文件，从而实现以下改进： - SST 可以被快速导入集群，从而提升恢复性能。 - 压缩过程中消除重复记录，从而减少空间消耗。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 1344521df4e3..45bf7eadbc63 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -505,7 +505,7 @@ tiup br restore point --pd="${PD_IP}:2379" ### 使用过滤器恢复 -从 TiDB v9.0.0 开始，在按时间点恢复 (PITR) 过程中，你可以使用过滤器恢复特定的数据库或表，从而更精细地控制要恢复的数据。 +从 TiDB v8.5.5 和 v9.0.0 开始，在按时间点恢复 (PITR) 过程中，你可以使用过滤器恢复特定的数据库或表，从而更精细地控制要恢复的数据。 过滤器采用与其他 BR 操作相同的[表库过滤语法](/table-filter.md)： @@ -545,7 +545,7 @@ tiup br restore point --pd="${PD_IP}:2379" \ > **注意：** > -> - 使用过滤器恢复前，请确保目标集群中不存在与过滤器匹配的数据库或表，否则恢复将失败并报错。 +> - 使用过滤器恢复前，请确保目标集群中不存在与过滤器匹配的数据库或表，否则恢复将失败并报错。 > - 过滤器选项适用于快照备份和日志备份的恢复阶段。 > - 可以指定多个 `--filter` 选项来包含或排除不同的模式。 > - PITR 过滤暂不支持系统表。如果需要恢复特定的系统表，请使用 `br restore full` 命令并配合过滤器，注意该命令仅恢复快照备份数据（而非日志备份数据）。 @@ -557,7 +557,7 @@ tiup br restore point --pd="${PD_IP}:2379" \ ### 并发恢复操作 -从 TiDB v9.0.0 开始，你可以同时执行多个 PITR 恢复任务。该功能允许你并行恢复不同的数据集，从而提升大规模恢复场景下的效率。 +从 TiDB v8.5.5 和 v9.0.0 开始，你可以同时执行多个 PITR 恢复任务。该功能允许你并行恢复不同的数据集，从而提升大规模恢复场景下的效率。 并发恢复的使用示例： @@ -586,7 +586,7 @@ tiup br restore point --pd="${PD_IP}:2379" \ ### 进行中的日志备份与快照恢复的兼容性 -从 v9.0.0 开始，当存在日志备份任务时，如果**同时满足**以下条件，则可以正常进行快照恢复 (`br restore [full|database|table]`)，并且恢复的数据可以被进行中的日志备份（下称“日志备份”）正常记录： +从 v8.5.5 和 v9.0.0 开始，当存在日志备份任务时，如果**同时满足**以下条件，则可以正常进行快照恢复 (`br restore [full|database|table]`)，并且恢复的数据可以被进行中的日志备份（下称“日志备份”）正常记录： - 执行备份恢复操作的节点需要同时具备以下权限： - 对备份来源外部存储的读取权限，用于执行快照恢复 @@ -604,11 +604,11 @@ tiup br restore point --pd="${PD_IP}:2379" \ > **注意：** > -> 当恢复记录了快照（全量）恢复数据的日志备份时，需要使用 v9.0.0 及之后版本的 BR，否则可能导致记录下来的全量恢复数据无法被恢复。 +> 当恢复记录了快照（全量）恢复数据的日志备份时，需要使用 v8.5.5 及之后版本的 BR，否则可能导致记录下来的全量恢复数据无法被恢复。 ### 进行中的日志备份与 PITR 操作的兼容性 -从 TiDB v9.0.0 开始，默认情况下，你可以在日志备份任务运行期间执行 PITR 操作。系统会自动处理这些操作之间的兼容性。 +从 TiDB v8.5.5 和 v9.0.0 开始，默认情况下，你可以在日志备份任务运行期间执行 PITR 操作。系统会自动处理这些操作之间的兼容性。 #### 进行中的日志备份与 PITR 的重要限制 diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 51c1a82c67e9..53a64c2af1c6 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -153,7 +153,7 @@ tiup br restore full \ - `br` v5.1.0 开始，快照备份时默认自动备份 **mysql schema 下的系统表数据**，但恢复数据时默认不恢复系统表数据。 - `br` v6.2.0 开始，增加恢复参数 `--with-sys-table` 支持恢复数据的同时恢复**部分系统表相关数据**。 - `br` v7.6.0 开始，恢复参数 `--with-sys-table` 默认开启，即默认支持恢复数据的同时恢复**部分系统表相关数据**。 -- `br` v9.0.0 开始，增加恢复参数 `--fast-load-sys-tables` 支持物理恢复系统表。通过 `RENAME TABLE` DDL 将 `__TiDB_BR_Temporary_mysql` 下的系统表和 `mysql` 库下的系统表进行原子交换。与通过 `REPLACE INTO` SQL 写入的逻辑恢复系统表方式不同，物理恢复系统表将会完全覆盖系统表中原有的数据。 +- `br` v8.5.5 和 v9.0.0 开始，增加恢复参数 `--fast-load-sys-tables` 支持物理恢复系统表。通过 `RENAME TABLE` DDL 将 `__TiDB_BR_Temporary_mysql` 下的系统表和 `mysql` 库下的系统表进行原子交换。与通过 `REPLACE INTO` SQL 写入的逻辑恢复系统表方式不同，物理恢复系统表将会完全覆盖系统表中原有的数据。 **可恢复的部分系统表**： diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 33ad94a3b459..e5cff13477e1 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -129,11 +129,11 @@ tiup br restore full \ > **注意：** > -> 从 v9.0.0 开始，当参数 `--load-stats` 设置为 `false` 时，br 不再向 `mysql.stats_meta` 表写入恢复表的统计信息。你可以在恢复完成后手动执行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)，以更新相关统计信息。 +> 从 v8.5.5 和 v9.0.0 开始，当参数 `--load-stats` 设置为 `false` 时，br 不再向 `mysql.stats_meta` 表写入恢复表的统计信息。你可以在恢复完成后手动执行 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)，以更新相关统计信息。 备份恢复功能在备份时，将统计信息通过 JSON 格式存储在 `backupmeta` 文件中。在恢复时，将 JSON 格式的统计信息导入到集群中。详情请参考 [LOAD STATS](/sql-statements/sql-statement-load-stats.md)。 -从 v9.0.0 开始，BR 引入参数 `--fast-load-sys-tables`，该参数默认开启。在使用 br 命令行工具将数据恢复到一个全新集群，且上下游的表和分区 ID 能够复用的前提下（否则会自动回退为逻辑导入统计信息），开启 `--fast-load-sys-tables` 后，br 会先将统计信息相关表恢复至临时系统库 `__TiDB_BR_Temporary_mysql` 中，再通过 `RENAME TABLE` 语句将这些表与 `mysql` 库下的原有表进行原子性替换。使用示例如下： +从 v8.5.5 和 v9.0.0 开始，BR 引入参数 `--fast-load-sys-tables`，该参数默认开启。在使用 br 命令行工具将数据恢复到一个全新集群，且上下游的表和分区 ID 能够复用的前提下（否则会自动回退为逻辑导入统计信息），开启 `--fast-load-sys-tables` 后，br 会先将统计信息相关表恢复至临时系统库 `__TiDB_BR_Temporary_mysql` 中，再通过 `RENAME TABLE` 语句将这些表与 `mysql` 库下的原有表进行原子性替换。使用示例如下： ```shell tiup br restore full \ @@ -192,7 +192,7 @@ Download&Ingest SST <----------------------------------------------------------- Restore Pipeline <-------------------------/...............................................> 17.12% ``` -从 TiDB v9.0.0 开始，你可以通过指定参数 `--fast-load-sys-tables` 在全新的集群上进行物理恢复系统表： +从 TiDB v8.5.5 和 v9.0.0 开始，你可以通过指定参数 `--fast-load-sys-tables` 在全新的集群上进行物理恢复系统表： ```shell tiup br restore full \ diff --git a/system-variables.md b/system-variables.md index 96c9a382296a..838958fafecd 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1289,7 +1289,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 这个变量用于控制是否开启[自动捕获绑定](/sql-plan-management.md#自动捕获绑定-baseline-capturing)功能。该功能依赖 Statement Summary，因此在使用自动绑定之前需打开 Statement Summary 开关。 - 开启该功能后会定期遍历一次 Statement Summary 中的历史 SQL 语句，并为至少出现两次的 SQL 语句自动创建绑定。 -### `tidb_cb_pd_metadata_error_rate_threshold_ratio` 从 v9.0.0 版本开始引入 +### `tidb_cb_pd_metadata_error_rate_threshold_ratio` 从 v8.5.5 和 v9.0.0 版本开始引入 - 作用域：GLOBAL - 是否持久化到集群：是 @@ -1568,7 +1568,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 当设置 `tidb_ddl_enable_fast_reorg` 为 `OFF` 时，`ADD INDEX` 会通过事务的方式执行，执行时如果 `ADD INDEX` 的目标列有较多 `UPDATE` 或者 `REPLACE` 等更新操作，batch size 设置的值越大，事务冲突的概率也会越大。此时建议调小 batch size 的值，最小值是 32。 - 在没有事务冲突的情况下，或者当 `tidb_ddl_enable_fast_reorg` 为 `ON` 时，batch size 可设为较大值，这样回填数据的速度更快，但是 TiKV 的写入压力也会变大。设置 batch size 时需要参考 `tidb_ddl_reorg_worker_cnt` 的设置值，详情见[线上负载与 `ADD INDEX` 相互影响测试](/benchmark/online-workloads-and-add-index-operations.md)。 - 从 v8.3.0 版本开始，该参数支持 SESSION 级别的设置，因此修改 GLOBAL 级别的参数值不会影响当前正在运行的 DDL，而只会对新建 SESSION 中提交的 DDL 生效。 - - 从 v8.5.0 版本开始，该参数可以通过 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;` 来修改。 + - 从 v8.5.0 版本开始，该参数可以通过 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;` 来修改。更多信息，请参考 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)。 ### `tidb_ddl_reorg_priority` @@ -1611,7 +1611,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 单位：线程 - 这个变量用来设置 DDL 操作 `re-organize` 阶段的并发度。 - 从 v8.3.0 版本开始，该参数支持 SESSION 级别的设置，因此修改 GLOBAL 级别的参数值不会影响当前正在运行的 DDL，而只会对新建 SESSION 中提交的 DDL 生效。 -- 从 v8.5.0 版本开始，该参数可以通过 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;` 来修改。 +- 从 v8.5.0 版本开始，该参数可以通过 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;` 来修改。更多信息，请参考 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)。 ### `tidb_enable_fast_create_table` 从 v8.0.0 版本开始引入 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index d57bd6bfa61e..27536023800a 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -645,7 +645,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `enable-async-batch-get` 从 v8.5.5 和 v9.0.0 版本开始引入 + 用于控制 TiDB 是否使用异步方式执行 Batch Get 算子。使用异步方式能够降低 goroutine 开销，提供更优的性能。通常无需调整该配置项。 -+ 默认值：`true` ++ 默认值：从 v9.0.0 起，默认值为 `true`。在 v8.5.5 中，默认值为 `false`。 ## opentracing