From e5f5c793526034ab81cc8bed31a1eadbee62d81b Mon Sep 17 00:00:00 2001 From: shichun-0415 <89768198+shichun-0415@users.noreply.github.com> Date: Mon, 21 Nov 2022 16:45:57 +0800 Subject: [PATCH] br: fix typos and add correct aliases (#12044) --- br/backup-and-restore-overview.md | 4 ++-- br/backup-and-restore-storages.md | 2 +- br/br-log-architecture.md | 6 +++--- br/br-monitoring-and-alert.md | 2 +- br/br-pitr-guide.md | 8 +++----- br/br-snapshot-architecture.md | 2 +- br/br-snapshot-guide.md | 4 ++-- br/br-use-overview.md | 4 ++-- br/external-storage.md | 1 - faq/backup-and-restore-faq.md | 8 ++++---- 10 files changed, 19 insertions(+), 22 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index df86b939830e..f0c4bdfcfdd1 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -49,7 +49,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求： #### 备份的性能，以及对集群的影响 - 集群快照数据备份，对 TiDB 集群的影响可以保持在 20% 以下；通过合理的配置 TiDB 集群用于备份资源，影响可以降低到 10% 及更低；单 TiKV 存储节点的备份速度可以达到 50 MB/s ～ 100 MB/s，备份速度具有可扩展性；更详细说明请参考[备份性能和影响](/br/br-snapshot-guide.md#快照备份的性能与影响)。 -- 单独运行日志备份时影响约在 5%。日志备份每隔 5～10 分钟将新上次刷新后产生变更数据记录全部刷新到备份存储中，可以**实现低至十分钟 RPO 的集群容灾目标**。 +- 单独运行日志备份时影响约在 5%。日志备份每隔 5～10 分钟将上次刷新后产生的变更数据记录刷新到备份存储中，可以**实现低至十分钟 RPO 的集群容灾目标**。 ### 恢复备份数据 @@ -66,7 +66,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求： #### 恢复的性能 - 恢复集群快照数据备份，速度可以达到单 TiKV 存储节点 100 MiB/s，恢复速度具有可扩展性；BR 只支持恢复数据到新集群，会尽可能多的使用恢复集群的资源。更详细说明请参考[恢复性能和影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)。 -- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 性能和影响](/br/br-pitr-guide.md#性能与影响)。 +- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 性能和影响](/br/br-pitr-guide.md#pitr-的性能与影响)。 ## 备份存储 diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 92cb88fac05b..6f130e84bfcf 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -1,7 +1,7 @@ --- title: 备份存储 summary: 了解 BR 支持的备份存储服务的 URL 格式、鉴权方案和使用方式。 -aliases: ['/zh/tidb/dev/backup-storage-S3/','/zh/tidb/dev/backup-storage-azblob/','/zh/tidb/dev/backup-storage-gcs/'] +aliases: ['/docs-cn/dev/br/backup-and-restore-storages/','/zh/tidb/dev/backup-storage-S3/','/zh/tidb/dev/backup-storage-azblob/','/zh/tidb/dev/backup-storage-gcs/'] --- # 备份存储 diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 6cd3e266ef2a..9e3eed959724 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -21,7 +21,7 @@ summary: 了解 TiDB 的日志备份与 PITR 的架构设计。 系统组件和关键概念： -* **local meta**：表示单 TiKV 节点备份下来的数据元信息，主要包括：local checkpoint ts、global checkpoint ts、备份文件信息。 +* **local metadata**：表示单 TiKV 节点备份下来的数据元信息，主要包括：local checkpoint ts、global checkpoint ts、备份文件信息。 * **local checkpoint ts** (in local metadata)：表示这个 TiKV 中所有小于 local checkpoint ts 的日志数据已经备份到目标存储。 * **global checkpoint ts**：表示所有 TiKV 中小于 global checkpoint ts 的日志数据已经备份到目标存储。它由运行在 TiDB 中的 Coordinator 模块收集所有 TiKV 的 local checkpoint ts 计算所得，然后上报给 PD。 * **TiDB Coordinator 组件**：TiDB 集群的某个节点会被选举为 Coordinator，负责收集和计算整个日志备份任务的进度 (global checkpoint ts)。该组件设计上无状态，在其故障后可以从存活的 TiDB 节点中重新选出一个节点作为 Coordinator。 @@ -59,7 +59,7 @@ PITR 的流程如下： 1. BR 接收恢复命令 `br restore point`。 * 解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。 - * 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否符合要求不存在。 + * 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否存在并符合要求。 2. BR 恢复全量备份。 * 进行快照备份数据恢复，恢复流程参考[恢复快照备份数据](/br/br-snapshot-architecture.md#恢复流程)。 @@ -88,7 +88,7 @@ PITR 的流程如下： 日志备份会产生如下类型文件： - `{min_ts}-{uuid}.log` 文件：存储备份下来的 kv 数据变更记录。其中 `{min_ts}` 是该文件中所有 kv 数据变更记录数对应的最小 ts；`{uuid}` 是生成该文件的时候随机生成的。 -- `{checkpoint_ts}-{uuid}.meta` 文件：每个 TiKV 节点每次上传日志备份数据时会生成一个该文件，保存本次上传的所有日志备份数据文件其中 `{checkpoint_ts}` 是本节点的日志备份的 checkpoint，所有 TiKV 节点的最小的 checkpoint 就是日志备份任务最新的 checkpoint；`{uuid}` 是生成该文件的时候随机生成的。 +- `{checkpoint_ts}-{uuid}.meta` 文件：每个 TiKV 节点每次上传日志备份数据时会生成一个该文件，保存本次上传的所有日志备份数据文件。其中 `{checkpoint_ts}` 是本节点的日志备份的 checkpoint，所有 TiKV 节点的最小的 checkpoint 就是日志备份任务最新的 checkpoint；`{uuid}` 是生成该文件的时候随机生成的。 - `{store_id}.ts` 文件：每个 TiKV 节点每次上传日志备份数据时会使用 global checkpoint ts 更新该文件。其中 `{store_id}` 是 TiKV 的 store ID。 - `v1_stream_truncate_safepoint.txt` 文件：保存最近一次通过 `br log truncate` 删除日志备份数据后，存储中最早的日志备份数据对应的 ts。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index eb2ac8e4f954..cb46b228fb66 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -44,7 +44,7 @@ aliases: ['/zh/tidb/dev/pitr-monitoring-and-alert/'] | **tikv_log_backup_flush_file_size** | Histogram | 备份产生的文件的大小统计。 | | **tikv_log_backup_initial_scan_duration_sec** | Histogram | 增量扫的整体耗时统计。 | | **tikv_log_backup_skip_retry_observe** | Counter | 在日志备份过程中，遇到的可忽略错误的统计，即放弃 retry 的原因。
`reason :: {"region-absent", "not-leader", "stale-command"}` | -| **tikv_log_backup_initial_scan_operations** | Counter | 增量扫过程中， RocksDB 相关的操作统计。
`cf :: {"default", "write", "lock"}, op :: RocksDBOP` | +| **tikv_log_backup_initial_scan_operations** | Counter | 增量扫过程中，RocksDB 相关的操作统计。
`cf :: {"default", "write", "lock"}, op :: RocksDBOP` | | **tikv_log_backup_enabled** | Counter | 日志备份功能是否开启，若值大于 0，表示开启 | | **tikv_log_backup_observed_region** | Gauge | 被监听的 Region 数量 | | **tikv_log_backup_task_status** | Gauge | 日志备份任务状态，0-Running 1-Paused 2-Error
`task :: string` | diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index fc9241adef10..7644534a5d30 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -14,7 +14,7 @@ aliases: ['/zh/tidb/dev/pitr-usage/'] ### 开启日志备份 -执行 `br log start` 命令启动日志备份任务，一个集群只能启动一个日志备份任务。该命令输出结果如下： +执行 `br log start` 命令启动日志备份任务，一个集群只能启动一个日志备份任务。 ```shell tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \ @@ -98,9 +98,7 @@ Restore KV Files <-------------------------------------------------------------- rm -rf s3://backup-101/snapshot-${date} ``` -## 性能与影响 - -### PITR 的性能与影响 +## PITR 的性能与影响 ### 能力指标 @@ -131,5 +129,5 @@ Restore KV Files <-------------------------------------------------------------- ## 探索更多 * [TiDB 集群备份与恢复实践示例](/br/backup-and-restore-use-cases.md) -* [br 命令行手册](/br/use-br-command-line-tool.md) +* [`br` 命令行手册](/br/use-br-command-line-tool.md) * [日志备份与 PITR 架构设计](/br/br-log-architecture.md) diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 9680cfb30d4c..b5ba576dbe18 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -59,7 +59,7 @@ summary: 了解 TiDB 快照备份与恢复功能的架构设计。 2. BR 调度恢复数据。 * **Pause Region schedule**：请求 PD 在恢复期间关闭自动 Region schedule。 - * **Restore schema**：读取备份数据的 schema、恢复的 database 和 table（注意新建表的 table id 与备份数据可能不一样）。 + * **Restore schema**：读取备份数据的 schema、恢复的 database 和 table（注意新建表的 table ID 与备份数据可能不一样）。 * **Split & scatter Region**：BR 基于备份数据信息，请求 PD 分配 Region (split Region)，并调度 Region 均匀分布到存储节点上 (scatter Region)。每个 Region 都有明确的数据范围 [start key, end key)。 * **Request TiKV to restore data**：根据 PD 分配的 Region 结果，发送恢复请求到对应的 TiKV 节点，恢复请求包含要恢复的备份数据及 rewrite 规则。 diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 97fb0a2a3ab4..0c75a969f97b 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -66,7 +66,7 @@ tiup br restore full --pd "${PD_IP}:2379" \ --storage "s3://backup-101/snapshot-202209081330?access_key=${access_key}&secret_access_key=${secret_access_key}" ``` -在恢复快照备份数据过程中，终端会显示备份进度条。在完成恢复后，会输出恢复耗时、速度、恢复数据大小等信息。 +在恢复快照备份数据过程中，终端会显示恢复进度条。在完成恢复后，会输出恢复耗时、速度、恢复数据大小等信息。 ```shell Full Restore <------------------------------------------------------------------------------> 100.00% @@ -174,4 +174,4 @@ TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响， * [TiDB 集群备份与恢复实践示例](/br/backup-and-restore-use-cases.md) * [`br` 命令行手册](/br/use-br-command-line-tool.md) -* [快照备份与恢复架构设计](/br/br-snapshot-architecture.md) \ No newline at end of file +* [快照备份与恢复架构设计](/br/br-snapshot-architecture.md) diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 086180688a81..027ca8b9cfed 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -77,7 +77,7 @@ Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是 BR 推荐的存 TiDB 支持使用 br 工具进行备份恢复。 * 安装方法可以使用[使用 TiUP 在线安装](/migration-tools.md#使用-tiup-快速安装)：`tiup install br`。 -* 了解如何使用 `br` 命令含工具进行备份与恢复，请参阅： +* 了解如何使用 `br` 命令行工具进行备份与恢复，请参阅： * [TiDB 快照备份与恢复功能使用](/br/br-snapshot-guide.md) * [TiDB 日志备份与 PITR 功能使用](/br/br-pitr-guide.md) @@ -93,7 +93,7 @@ TiDB 支持使用 SQL 语句进行全量快照备份和恢复： ### 在 Kubernetes 环境下通过 TiDB Operator -在 Kubernetes 环境下，支持通过 TiDB Operator 支持以 S3、GCS、Azure blob storage 作为备份存储。使用文档请参阅[使用 TiDB Operator 进行备份恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-overview)。 +在 Kubernetes 环境下，支持通过 TiDB Operator 支持以 S3、GCS、Azure blob storage 作为备份存储，并从这些存储系统中恢复备份数据。使用文档请参阅[使用 TiDB Operator 进行备份恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-overview)。 ## 探索更多 diff --git a/br/external-storage.md b/br/external-storage.md index 789f9eae4c63..6cf52dafa74d 100644 --- a/br/external-storage.md +++ b/br/external-storage.md @@ -1,7 +1,6 @@ --- title: 外部存储 summary: 了解 BR、TiDB Lightning 和 Dumpling 中所用外部存储服务的 URL 参数。 -aliases: ['/docs-cn/dev/br/backup-and-restore-storages/'] --- # 外部存储 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index dabb1c39b20f..d4dac9d55f2a 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -119,7 +119,7 @@ checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s > > 由于此功能会备份集群的多版本数据，当任务发生错误且状态变更为 `ERROR` 时，同时会将当前任务的备份进度点的数据设为一个 `safe point`，`safe point` 的数据将保证 24 小时不被 GC 掉。所以，当任务恢复之后，会从上一个备份点继续备份日志。如果任务失败时间超过 24 小时，前一次备份进度点的数据就已经 GC，此时恢复任务操作会提示失败。这种场景下，只能执行 `br log stop` 命令先停止本次任务，然后重新开启新的备份任务。 -## 执行 `br log resume` 命令恢复处于暂停状态的任务时报 `ErrBackupGCSafepointExceeded` 错误，该如何处理？ +### 执行 `br log resume` 命令恢复处于暂停状态的任务时报 `ErrBackupGCSafepointExceeded` 错误，该如何处理？ ```shell Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded @@ -131,7 +131,7 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo ## 功能兼容性问题 -### BR 恢复到 TiCDC / Drainer 的上游集群时，要注意些什么？ +### 为什么 BR 恢复的数据无法同步到 TiCDC / Drainer 的上游集群？ - **BR 恢复的数据无法被同步到下游**，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。 - 在 4.0.3 版本之前，BR 恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。 @@ -270,9 +270,9 @@ BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)。BR v6. 由以上命令输出结果可知，`tikv-server` 实例由用户 `tidb_ouo` 启动，但该账号没有 `backup` 目录的写入权限， 所以备份失败。 -## 恢复集群的时候，在 MySQL 下的业务表为什么没有恢复？ +### 恢复集群的时候，在 MySQL 下的业务表为什么没有恢复？ -自 BR v5.1.0 开始，全量备份会备份**mysql schema 下的表**。BR v6.2.0 以前的版本，在默认设置不会恢复**mysql schema 下的表**。 +自 BR v5.1.0 开始，全量备份会备份 **mysql schema 下的表**。BR v6.2.0 以前的版本，在默认设置不会恢复 **mysql schema 下的表**。 如果需要恢复 `mysql` 下的用户创建的表（非系统表），可以通过 [table filter](/table-filter.md#表库过滤语法) 来显式地包含目标表。以下示例中命令会在执行正常的恢复的同时恢复 `mysql.usertable`。