fix 2 issues (pingcap#16202)

shawn0915 · Jan 19, 2024 · 960d0fd · 960d0fd
1 parent 9eb766f
commit 960d0fd
Show file tree

Hide file tree

Showing 4 changed files with 12 additions and 14 deletions.
diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md
@@ -94,7 +94,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求：
 #### 恢复的性能
 
 - 恢复集群快照数据备份，速度可以达到单 TiKV 存储节点 100 MiB/s，恢复速度具有可扩展性；BR 只支持恢复数据到新集群，会尽可能多的使用恢复集群的资源。更详细说明请参考[恢复性能和影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)。
-- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 性能和影响](/br/br-pitr-guide.md#pitr-的性能与影响)。
+- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 的性能指标](/br/br-pitr-guide.md#pitr-的性能指标)。
 
 ## 备份存储
 

diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md
@@ -103,9 +103,7 @@ Restore KV Files <--------------------------------------------------------------
     rm -rf s3://backup-101/snapshot-${date}
     ```
 
-## PITR 的性能与影响
-
-### 能力指标
+## PITR 的性能指标
 
 - PITR 恢复速度，平均到单台 TiKV 节点：全量恢复为 280 GB/h，日志恢复为 30 GB/h
 - 使用 `br log truncate` 清理过期的日志备份数据速度为 600 GB/h
@@ -121,7 +119,7 @@ Restore KV Files <--------------------------------------------------------------
 > 所有测试集群默认设置 3 副本。
 > 如果想提升整体恢复的性能，可以通过根据实际情况调整 TiKV 配置文件中的 [`import.num-threads`](/tikv-configuration-file.md#import) 配置项以及 BR 命令的 [`concurrency`](/br/use-br-command-line-tool.md#常用选项) 参数。
 
-测试场景 1（[TiDB Cloud](https://tidbcloud.com) 上部署）
+测试场景 1（[TiDB Cloud](https://tidbcloud.com) 上部署）如下：
 
 - TiKV 节点（8 core，16 GB 内存）数量：21
 - TiKV 配置项 `import.num-threads`：8
@@ -130,7 +128,7 @@ Restore KV Files <--------------------------------------------------------------
 - 集群新增日志数据：10 GB/h
 - 写入 (INSERT/UPDATE/DELETE) QPS：10,000
 
-测试场景 2（本地部署）
+测试场景 2（本地部署）如下：
 
 - TiKV 节点（8 core，64 GB 内存）数量：6
 - TiKV 配置项 `import.num-threads`：8

diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md
@@ -93,7 +93,7 @@ BR 作为 TiDB 的备份恢复工具，可以对 TiDB 集群进行基于时间
 
 按照上面的部署，TiDB Cluster1 部署在区域 1 (Region 1)，BR 工具定期将集群的数据备份到区域 2 (Region 2)，并且持续将数据改变日志也备份到区域 2。当区域 1 出现灾难导致 Cluster1 无法恢复时，你可以使用备份的数据和数据改变在区域 2 恢复新的集群 Cluster2 对外提供服务。
 
-基于备份恢复的容灾方案，目前，RPO 低于 5 分钟，而 RTO 则取决于需要恢复的集群数据大小，对于 v6.5.0 版本的 BR，其恢复速度可以参考[快照恢复的性能与影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)和 [PITR 的性能与影响](/br//br-pitr-guide.md#pitr-的性能与影响)。通常来说，大部分客户会把跨区域 的备份作为数据安全的最后一道防线，是大多数系统都需要的。对于该方案的详细信息，请参考[基于备份与恢复的容灾方案](/dr-backup-restore.md)。
+基于备份恢复的容灾方案，目前，RPO 低于 5 分钟，而 RTO 则取决于需要恢复的集群数据大小，对于 v6.5.0 版本的 BR，其恢复速度可以参考[快照恢复的性能与影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)和 [PITR 的性能指标](/br//br-pitr-guide.md#pitr-的性能指标)。通常来说，大部分客户会把跨区域 的备份作为数据安全的最后一道防线，是大多数系统都需要的。对于该方案的详细信息，请参考[基于备份与恢复的容灾方案](/dr-backup-restore.md)。
 
 另外，从 v6.5.0 开始，BR 支持[基于 AWS 上的 EBS 快照的快速恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/restore-from-aws-s3-by-snapshot)。如果你在 AWS 上运行 TiDB 集群，要求备份过程对集群没有任何影响，并且要求恢复的时间尽量短，可以考虑使用该特性来降低系统的 RTO。
 

diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md
@@ -52,7 +52,7 @@ Value:
 
 + **Key:**
 
-    ```
+    ```json
     {
         "ts":<TS>,
         "scm":<Schema Name>,
@@ -71,7 +71,7 @@ Value:
 
     `Insert` 事件，输出新增的行数据。
 
-    ```
+    ```json
     {
         "u":{
             <Column Name>:{
@@ -92,7 +92,7 @@ Value:
 
     `Update` 事件，输出新增的行数据 ("u") 以及修改前的行数据 ("p")。
 
-    ```
+    ```json
     {
         "u":{
             <Column Name>:{
@@ -127,7 +127,7 @@ Value:
 
     `Delete` 事件，输出被删除的行数据。
 
-    ```
+    ```json
     {
         "d":{
             <Column Name>:{
@@ -158,7 +158,7 @@ Value:
 
 + **Key:**
 
-    ```
+    ```json
     {
         "ts":<TS>,
         "scm":<Schema Name>,
@@ -175,7 +175,7 @@ Value:
 
 + **Value:**
 
-    ```
+    ```json
     {
         "q":<DDL Query>,
         "t":<DDL Type>
@@ -191,7 +191,7 @@ Value:
 
 + **Key:**
 
-    ```
+    ```json
     {
         "ts":<TS>,
         "t":3