Skip to content

Commit cf99f1e

Browse files
qiancaiqiancai
committed
add workflow
1 parent 5f5c30e commit cf99f1e

File tree

2 files changed

+96
-3
lines changed

2 files changed

+96
-3
lines changed

‎.github/workflows/code_review.yml‎

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
name: AI Code Review
2+
3+
on:
4+
pull_request:
5+
types:
6+
- opened
7+
- synchronize
8+
- reopened
9+
10+
permissions: write-all
11+
12+
jobs:
13+
review:
14+
runs-on: ubuntu-latest
15+
steps:
16+
- name: Checkout Repo
17+
uses: actions/checkout@v3
18+
19+
- name: AI Code Reviewer
20+
uses: qiancai/ai-codereviewer@test
21+
with:
22+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
23+
API_PROVIDER: "deepseek" # or "openai" if you want to use OpenAI
24+
DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
25+
DEEPSEEK_API_MODEL: "deepseek-chat" # Updated model name
26+
exclude: "**/*.json" # Optional: exclude patterns separated by commas

‎br/br-checkpoint-restore.md‎

Lines changed: 70 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ summary: 了解断点恢复功能，包括它的使用场景、实现原理以
55

66
# 断点恢复
77

8-
快照恢复或日志恢复会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等等一些突发情况。在 TiDB v7.1.0 之前，在错误被处理之后，之前恢复的进度会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。
8+
快照恢复或日志恢复会因为一些可恢复性错误导致提前结，例如硬盘空间占满,节点宕机等等一些突发情况。.在 TiDB v7.1.0 之前，在错误被处理之后，之前恢复的的进度会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。
99

1010
为了尽可能继续上一次的恢复，从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能。该功能可以在意外中断后保留上一次恢复的大部分进度。
1111

@@ -65,7 +65,11 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold
6565

6666
不建议进行跨大版本的断点恢复操作。对于使用 v8.5.0 之前长期支持 (Long-Term Support, LTS) 版本 br 恢复失败的集群，无法通过 v8.5.0 或更新的 LTS 版本 br 继续恢复，反之亦然。
6767

68-
## 实现细节
68+
## 实现细节：将断点数据存储在下游集群
69+
70+
> **注意：**
71+
>
72+
> 在 v9.0.0 之后，默认将断点数据存储在下游集群，但你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。
6973
7074
断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。
7175

@@ -81,8 +85,71 @@ br 工具暂停 GC 的原理是通过执行 `SET config tikv gc.ratio-threshold
8185

8286
[PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。
8387

84-
在第一次执行恢复时，br 工具首先进入快照恢复阶段。该阶段与上述只进行[快照恢复](#快照恢复-1)操作相同，断点数据，以及备份数据的上游集群的 ID 和备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts`。
88+
在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID 、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint` 数据库中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。
89+
90+
> **注意：**
91+
>
92+
> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。
8593
8694
在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 `__TiDB_BR_Temporary_Log_Restore_Checkpoint` 数据库，然后使用其他备份重试。
8795

8896
在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。
97+
98+
## 实现细节：将断点数据存储在外部存储
99+
100+
> **注意：**
101+
>
102+
> 在 v9.0.0 之后，默认将断点数据存储在下游集群，但你可以通过参数 `--checkpoint-storage` 来指定断点数据存储的外部存储。
103+
>
104+
> 例如：`./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"`
105+
106+
存储在外部存储中的断点数据存在以下目录格式。主路径 `restore-{downstream-cluster-ID}` 中的下游集群 ID `{downstream-cluster-ID}` 用于区分不同恢复集群。路径 `restore-{downstream-cluster-ID}/log` 存放的是日志恢复阶段的日志文件断点数据，路径 `restore-{downstream-cluster-ID}/sst` 存放的是日志恢复阶段的未被日志备份备份的 SST 文件恢复断点数据，路径 `restore-{downstream-cluster-ID}/snapshot` 存放的是快照恢复阶段的断点数据。
107+
108+
```
109+
.
110+
`-- restore-{downstream-cluster-ID}
111+
|-- log
112+
| |-- checkpoint.meta
113+
| |-- data
114+
| | |-- {uuid}.cpt
115+
| | |-- {uuid}.cpt
116+
| | `-- {uuid}.cpt
117+
| |-- ingest_index.meta
118+
| `-- progress.meta
119+
|-- snapshot
120+
| |-- checkpoint.meta
121+
| |-- checksum
122+
| | |-- {uuid}.cpt
123+
| | |-- {uuid}.cpt
124+
| | `-- {uuid}.cpt
125+
| `-- data
126+
| |-- {uuid}.cpt
127+
| |-- {uuid}.cpt
128+
| `-- {uuid}.cpt
129+
`-- sst
130+
`-- checkpoint.meta
131+
```
132+
133+
断点恢复的具体操作细节分为快照恢复和 PITR 恢复两部分。
134+
135+
### 快照恢复
136+
137+
在第一次执行恢复时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/snapshot`，用于记录断点数据，以及这次恢复的上游集群 ID 和备份的 BackupTS。
138+
139+
如果恢复执行失败，你可以使用相同的命令再次执行恢复，br 工具会从指定的存储断点数据的外部存储中读取断点信息，并从上次中断的位置继续恢复。
140+
141+
当恢复执行失败后，如果你尝试将与断点记录不同的备份数据恢复到同一集群，br 工具会报错，并提示上游集群 ID 或 BackupTS 与断点记录不同。如果恢复集群已被清理，你可以手动删除存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。
142+
143+
### PITR 恢复
144+
145+
[PITR (Point-in-time recovery)](/br/br-pitr-guide.md) 恢复分为快照恢复和日志恢复两个阶段。
146+
147+
在第一次执行恢复时，br 工具首先进入快照恢复阶段。断点数据，以及备份数据的上游集群的 ID、备份数据的 BackupTS（即日志恢复的起始时间点 `start-ts`）和 PITR恢复的 `restored-ts` 会被记录到路径 `restore-{downstream-cluster-ID}/snapshot` 中。如果在此阶段恢复失败，尝试继续断点恢复时无法再调整日志恢复的起始时间点 `start-ts` 和 `restored-ts`。
148+
149+
> **注意：**
150+
>
151+
> 在 v9.0.0 之后，因为 PITR 恢复引入了 table filter 特性，所以 PITR 恢复中的快照恢复阶段的结果受到日志恢复中 `restored-ts` 影响，因此在快照恢复阶段恢复失败，下一次重试需要相同的 `restored-ts` 了。
152+
153+
在第一次执行恢复并且进入日志恢复阶段时，br 工具会在恢复集群中创建路径 `restore-{downstream-cluster-ID}/log` 数据库，用于记录断点数据，以及这次恢复的上游集群 ID 和恢复的时间范围 `start-ts` 与 `restored-ts`。如果在此阶段恢复失败，重新执行恢复命令时，你需要指定与断点记录相同的 `start-ts` 和 `restored-ts` 参数，否则 br 工具会报错，并提示上游集群 ID 或恢复的时间范围与断点记录不同。如果恢复集群已被清理，你可以手动删除 存储在外部存储的断点数据或更换指定的断点数据存储路径，然后使用其他备份重试。
154+
155+
在第一次执行恢复并且进入日志恢复阶段前，br 工具会构造出在 `restored-ts` 时间点的上下游集群库表 ID 映射关系，并将其持久化到系统表 `mysql.tidb_pitr_id_map` 中，以避免库表 ID 被重复分配。如果删除 `mysql.tidb_pitr_id_map` 中的数据，可能会导致 PITR 恢复数据不一致。

0 commit comments

Comments
 (0)