From 6f9c0eed0a538e9bbb9e87b30c2ce806ac807931 Mon Sep 17 00:00:00 2001 From: Jianjun Liao Date: Wed, 26 Feb 2025 13:49:04 +0800 Subject: [PATCH 1/8] draft Signed-off-by: Jianjun Liao --- br/br-checkpoint-restore.md | 71 +++++++++++++++++++++++++++++++++++-- 1 file changed, 69 insertions(+), 2 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8bca50bb64d9..4d9927642280 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -65,7 +65,11 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold 不建议进行跨大版本的断点恢复操作。对于使用 v8.5.0 之前长期支持 (Long-Term Support, LTS) 版本 br 恢复失败的集群，无法通过 v8.5.0 或更新的 LTS 版本 br 继续恢复，反之亦然。 -## 实现细节 +## 实现细节：将断点数据存储在下游集群 + +> **注意：** +> +> 在 v9.0.0 之后，默认将断点数据存储在下游集群，但你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。 @@ -81,8 +85,71 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold [PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。 -在第一次执行恢复时，br 工具首先进入快照恢复阶段。该阶段与上述只进行[快照恢复](#快照恢复-1)操作相同，断点数据，以及备份数据的上游集群的 ID 和备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts`。 +在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 + +> **注意：** +> +> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。 在第一次执行恢复并且进入日志恢复阶段时，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 恢复数据不一致。 + +## 实现细节：将断点数据存储在外部存储 + +> **注意：** +> +> 在 v9.0.0 之后，默认将断点数据存储在下游集群，但你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 +> +> 例如：`./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"` + +存储在外部存储中的断点数据存在以下目录格式。主路径 `restore-{downstream-cluster-ID}` 中的下游集群 ID `{downstream-cluster-ID}` 用于区分不同恢复集群。路径 `restore-{downstream-cluster-ID}/log` 存放的是日志恢复阶段的日志文件断点数据，路径 `restore-{downstream-cluster-ID}/sst` 存放的是日志恢复阶段的未被日志备份备份的 SST 文件恢复断点数据，路径 `restore-{downstream-cluster-ID}/snapshot` 存放的是快照恢复阶段的断点数据。 + +``` +. +`-- restore-{downstream-cluster-ID} + |-- log + | |-- checkpoint.meta + | |-- data + | | |-- {uuid}.cpt + | | |-- {uuid}.cpt + | | `-- {uuid}.cpt + | |-- ingest_index.meta + | `-- progress.meta + |-- snapshot + | |-- checkpoint.meta + | |-- checksum + | | |-- {uuid}.cpt + | | |-- {uuid}.cpt + | | `-- {uuid}.cpt + | `-- data + | |-- {uuid}.cpt + | |-- {uuid}.cpt + | `-- {uuid}.cpt + `-- sst + `-- checkpoint.meta +``` + +断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。 + +### 快照恢复 + +在第一次执行恢复时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/snapshot`，用于记录断点数据，以及这次恢复的上游集群 ID 和备份的 BackupTS。 + +如果恢复执行失败，你可以使用相同的命令再次执行恢复，br 工具会从指定的存储断点数据的外部存储中读取断点信息，并从上次中断的位置继续恢复。 + +当恢复执行失败后，如果你尝试将与断点记录不同的备份数据恢复到同一集群，br 工具会报错，并提示上游集群 ID 或 BackupTS 与断点记录不同。如果恢复集群已被清理，你可以手动删除存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 + +### PITR 恢复 + +[PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。 + +在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到路径 `restore-{downstream-cluster-ID}/snapshot` 中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 + +> **注意：** +> +> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。 + +在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 + +在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。 From 9701f926ffff84b9b422c6c6a2b3a6c177720b95 Mon Sep 17 00:00:00 2001 From: Jianjun Liao <36503113+Leavrth@users.noreply.github.com> Date: Wed, 5 Mar 2025 12:09:23 +0800 Subject: [PATCH 2/8] Apply suggestions from code review Co-authored-by: xixirangrang --- br/br-checkpoint-restore.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 4d9927642280..d26fa1ccc36a 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` 来指定断点数据存储的外部存储。 +> 从 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。 @@ -85,11 +85,11 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold [PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。 -在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 +在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据、备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 > **注意：** > -> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。 +> 从 v9.0.0 开始，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此如果在快照恢复阶段恢复失败，下一次重试需要使用相同的 `restored-ts`。 在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，然后使用其他备份重试。 @@ -99,11 +99,16 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 在 v9.0.0 之后，默认将断点数据存储在下游集群，但你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 +> 从 v9.0.0 之后，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 > > 例如：`./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"` -存储在外部存储中的断点数据存在以下目录格式。主路径 `restore-{downstream-cluster-ID}` 中的下游集群 ID `{downstream-cluster-ID}` 用于区分不同恢复集群。路径 `restore-{downstream-cluster-ID}/log` 存放的是日志恢复阶段的日志文件断点数据，路径 `restore-{downstream-cluster-ID}/sst` 存放的是日志恢复阶段的未被日志备份备份的 SST 文件恢复断点数据，路径 `restore-{downstream-cluster-ID}/snapshot` 存放的是快照恢复阶段的断点数据。 +存储在外部存储中的断点数据存在以下目录格式： + +- 主路径 `restore-{downstream-cluster-ID}` 中的下游集群 ID `{downstream-cluster-ID}` 用于区分不同的恢复集群 +- 路径 `restore-{downstream-cluster-ID}/log` 存放日志恢复阶段的日志文件断点数据 +- 路径 `restore-{downstream-cluster-ID}/sst` 存放日志恢复阶段的未被日志备份备份的 SST 文件的恢复断点数据 +- 路径 `restore-{downstream-cluster-ID}/snapshot` 存放快照恢复阶段的断点数据 ``` . @@ -144,11 +149,11 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold [PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。 -在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到路径 `restore-{downstream-cluster-ID}/snapshot` 中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 +在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到路径 `restore-{downstream-cluster-ID}/snapshot` 中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 > **注意：** > -> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。 +> 从 v9.0.0 开始，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此如果在快照恢复阶段恢复失败，下一次重试需要使用相同的 `restored-ts`。 在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 From c20d3f239598b8a9c956393ec470e987eff3e50e Mon Sep 17 00:00:00 2001 From: Jianjun Liao Date: Mon, 10 Mar 2025 11:35:35 +0800 Subject: [PATCH 3/8] fix typos Signed-off-by: Jianjun Liao --- br/br-checkpoint-restore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index d26fa1ccc36a..8e91a8548c8f 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -155,6 +155,6 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > > 从 v9.0.0 开始，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此如果在快照恢复阶段恢复失败，下一次重试需要使用相同的 `restored-ts`。 -在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 +在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log`，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。 From 6b2eb49aa217a57159672131bab288d1fb3f8dc9 Mon Sep 17 00:00:00 2001 From: Jianjun Liao Date: Mon, 10 Mar 2025 14:42:26 +0800 Subject: [PATCH 4/8] commit some suggestions Signed-off-by: Jianjun Liao --- br/br-checkpoint-restore.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8e91a8548c8f..a5251573d05c 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -87,10 +87,6 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold 在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据、备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 -> **注意：** -> -> 从 v9.0.0 开始，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此如果在快照恢复阶段恢复失败，下一次重试需要使用相同的 `restored-ts`。 - 在第一次执行恢复并且进入日志恢复阶段时，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 恢复数据不一致。 @@ -151,10 +147,6 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold 在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到路径 `restore-{downstream-cluster-ID}/snapshot` 中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 -> **注意：** -> -> 从 v9.0.0 开始，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此如果在快照恢复阶段恢复失败，下一次重试需要使用相同的 `restored-ts`。 - 在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log`，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。 在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。 From 37beb7b1fa0c51ad674b4dec56d1ddbe2dc3f42d Mon Sep 17 00:00:00 2001 From: houfaxin Date: Tue, 8 Apr 2025 16:17:08 +0800 Subject: [PATCH 5/8] Update br-checkpoint-restore.md --- br/br-checkpoint-restore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index a5251573d05c..8197556a2969 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -15,7 +15,7 @@ summary: 了解断点恢复功能，包括它的使用场景、实现原理以 ## 实现原理 -断点恢复的实现原理分为快照恢复和日志恢复两部分。具体实现细节请参考[实现细节](#实现细节)。 +断点恢复的实现原理分为快照恢复和日志恢复两部分。具体实现细节请参考[实现细节将断点数据存储在下游集群](#实现细节将断点数据存储在下游集群)和[实现细节将断点数据存储在外部存储](#实现细节将断点数据存储在外部存储)。 ### 快照恢复 From 18af2e9575085e0c4b6f8367acaf6b691ed6b3d1 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Tue, 8 Apr 2025 16:18:17 +0800 Subject: [PATCH 6/8] Update br-checkpoint-restore.md --- br/br-checkpoint-restore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8197556a2969..39f0d147be75 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -15,7 +15,7 @@ summary: 了解断点恢复功能，包括它的使用场景、实现原理以 ## 实现原理 -断点恢复的实现原理分为快照恢复和日志恢复两部分。具体实现细节请参考[实现细节将断点数据存储在下游集群](#实现细节将断点数据存储在下游集群)和[实现细节将断点数据存储在外部存储](#实现细节将断点数据存储在外部存储)。 +断点恢复的实现原理分为快照恢复和日志恢复两部分。具体实现细节请参考[实现细节：将断点数据存储在下游集群](#实现细节将断点数据存储在下游集群)和[实现细节：将断点数据存储在外部存储](#实现细节将断点数据存储在外部存储)。 ### 快照恢复 From 1408d531843adccf26af961788f2cb47c997e0dc Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Thu, 10 Apr 2025 10:34:36 +0800 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Aolin --- br/br-checkpoint-restore.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 39f0d147be75..16af1ef4bf12 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -85,7 +85,7 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold [PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。 -在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据、备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 +在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据、备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR 恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。 在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，然后使用其他备份重试。 @@ -95,16 +95,18 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 从 v9.0.0 之后，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 +> 从 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。例如： > -> 例如：`./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"` +> ```shell +> ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" +> ``` -存储在外部存储中的断点数据存在以下目录格式： +在外部存储中，断点数据的目录结构如下： - 主路径 `restore-{downstream-cluster-ID}` 中的下游集群 ID `{downstream-cluster-ID}` 用于区分不同的恢复集群 -- 路径 `restore-{downstream-cluster-ID}/log` 存放日志恢复阶段的日志文件断点数据 -- 路径 `restore-{downstream-cluster-ID}/sst` 存放日志恢复阶段的未被日志备份备份的 SST 文件的恢复断点数据 -- 路径 `restore-{downstream-cluster-ID}/snapshot` 存放快照恢复阶段的断点数据 +- 路径 `restore-{downstream-cluster-ID}/log` 存储日志恢复阶段的日志文件断点数据 +- 路径 `restore-{downstream-cluster-ID}/sst` 存储日志恢复阶段中未被日志备份覆盖的 SST 文件的断点数据 +- 路径 `restore-{downstream-cluster-ID}/snapshot` 存储快照恢复阶段的断点数据 ``` . From a3cf7ba1c3a869cc8e50e1ab274d4fc5fcce7166 Mon Sep 17 00:00:00 2001 From: Lilian Lee Date: Thu, 25 Dec 2025 14:02:48 +0800 Subject: [PATCH 8/8] Update v9.0.0 to v8.5.5 --- br/br-checkpoint-restore.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 16af1ef4bf12..6411e53042a3 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 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。 断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。 @@ -95,7 +95,7 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold > **注意：** > -> 从 v9.0.0 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。例如： +> 从 v8.5.5 开始，默认将断点数据存储在下游集群。你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。例如： > > ```shell > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"