pingcap · qiancai · Dec 3, 2025 · Dec 12, 2025 · Dec 12, 2025 · Dec 23, 2025
diff --git 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
@@ -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
@@ -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 或 v9.0.0 及之后版本的 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
@@ -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
@@ -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
@@ -1278,7 +1278,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` <span class="version-mark">从 v9.0.0 版本开始引入</span>
+### `tidb_cb_pd_metadata_error_rate_threshold_ratio` <span class="version-mark">从 v8.5.5 和 v9.0.0 版本开始引入</span>
 
 - 作用域：GLOBAL
 - 是否持久化到集群：是

diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md
@@ -29,7 +29,7 @@ null = '\N'
 include-commit-ts = true
 binary-encoding-method = 'base64'
 output-old-value = false
-output-field-header = false # 从 v9.0.0 开始引入
+output-field-header = false # 从 v8.5.5 和 v9.0.0 开始引入
 ```
 
 ## 数据保存的事务性约束