restore: update the definition of the parameter --load-stats and the usage of pitr id map
#20346
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Jianjun Liao <[email protected]>
Signed-off-by: Jianjun Liao <[email protected]>
ti-chi-bot
bot
added
missing-translation-status
BornChanger
reviewed
May 19, 2025
BornChanger
reviewed
May 19, 2025
BornChanger
reviewed
May 19, 2025
Oreoxmt
added
translation/doing
ti-chi-bot
bot
removed
the
missing-translation-status
Signed-off-by: Jianjun Liao <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ti-chi-bot
bot
added
size/M
Co-authored-by: BornChanger <[email protected]>
Signed-off-by: Jianjun Liao <[email protected]>
…cn into load_stats_and_pitr_id_map
Signed-off-by: Jianjun Liao <[email protected]>
Signed-off-by: Jianjun Liao <[email protected]>
16 tasks
lilin90
added
translation/done
lilin90
added
the
type/compatibility-or-feature-change
lilin90
reviewed
Jun 11, 2025
| @@ -89,7 +89,11 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold | |||
|
|
|||
| 在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，然后使用其他备份重试。 | |||
|
|
|||
| 在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。 | |||
| 在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。**如果随意删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。** | |||
There was a problem hiding this comment.
- Line 86 写到“PITR 恢复分为快照恢复和日志恢复两个阶段”，下面这三段看起来像分了三个阶段。请看下是否调整该小节开头的描述，或者这三段的逻辑和呈现？
- 另外，从字面语义上看，“在第一次执行恢复并且进入日志恢复阶段前”应该放在“在第一次执行恢复并且进入日志恢复阶段时”前面？
| @@ -132,8 +132,19 @@ tiup br restore full \ | |||
| --storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log | |||
| ``` | |||
|
|
|||
| > **注意：** | |||
| > | |||
| > 从 v9.0.0 起，当设置参数 `--load-stats` 为 false 时，br 将不会在表 `mysql.stats_meta` 中更新恢复的表的相关信息。你可以在恢复完成后手动执行 analyze table，更新相关统计信息。 | |||
There was a problem hiding this comment.
Suggested change
| > 从 v9.0.0 起，当设置参数 `--load-stats` 为 false 时，br 将不会在表 `mysql.stats_meta` 中更新恢复的表的相关信息。你可以在恢复完成后手动执行 analyze table，更新相关统计信息。 | |
| > 从 v9.0.0 起，当参数 `--load-stats` 设置为 `false` 时，br 不再向 `mysql.stats_meta` 表写入恢复表的统计信息。你可以在恢复完成后手动执行 `ANALYZE TABLE`，以更新相关统计信息。 |
| 备份恢复功能在备份时，将统计信息通过 JSON 格式存储在 `backupmeta` 文件中。在恢复时，将 JSON 格式的统计信息导入到集群中。详情请参考 [LOAD STATS](/sql-statements/sql-statement-load-stats.md)。 | ||
|
|
||
| 从 9.0.0 起，BR 引入参数 `--fast-load-sys-tables`，默认开启。当 br 命令行工具恢复在全新集群并且上下游表和分区的 ID 都能被复用时（否则，将自动回退为逻辑导入统计信息数据），通过设置 `--fast-load-sys-tables` 会将统计信息相关表恢复到临时系统库 `__TiDB_BR_Temporary_mysql` 中，再通过 `RENAME TABLE` DDL 将恢复的统计信息表和 `mysql` 库下的表进行原子交换。示例如下： |
There was a problem hiding this comment.
Suggested change
| 从 9.0.0 起，BR 引入参数 `--fast-load-sys-tables`，默认开启。当 br 命令行工具恢复在全新集群并且上下游表和分区的 ID 都能被复用时（否则，将自动回退为逻辑导入统计信息数据），通过设置 `--fast-load-sys-tables` 会将统计信息相关表恢复到临时系统库 `__TiDB_BR_Temporary_mysql` 中，再通过 `RENAME TABLE` DDL 将恢复的统计信息表和 `mysql` 库下的表进行原子交换。示例如下： | |
| 从 v9.0.0 起，BR 引入参数 `--fast-load-sys-tables`，该参数默认开启。在使用 br 命令行工具将数据恢复到一个全新集群，且上下游的表和分区 ID 能够复用的前提下（否则会自动回退为逻辑导入统计信息），开启 `--fast-load-sys-tables` 后，br 会先将统计信息相关表恢复至临时系统库 `__TiDB_BR_Temporary_mysql` 中，再通过 `RENAME TABLE` 语句将这些表与 `mysql` 库下的原有表进行原子性替换。使用示例如下： |
|
|
||
| > **注意：** | ||
| > | ||
| > 与通过 `REPLACE INTO` SQL 写入的逻辑恢复系统表方式不同，物理恢复系统表将会完全覆盖系统表中原有的数据。 |
There was a problem hiding this comment.
Suggested change
| > 与通过 `REPLACE INTO` SQL 写入的逻辑恢复系统表方式不同，物理恢复系统表将会完全覆盖系统表中原有的数据。 | |
| > 与通过 `REPLACE INTO` SQL 语句执行的逻辑恢复系统表方式不同，物理恢复系统表会完全覆盖系统表中的原有数据。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First-time contributors' checklist
What is changed, added or deleted? (Required)
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions (in Chinese).
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?