From 7792427db4ecd4a316709c32a7c51f75d8818e60 Mon Sep 17 00:00:00 2001 From: onlymellb Date: Fri, 28 Feb 2020 11:40:11 +0800 Subject: [PATCH 1/4] cherry pick #2236 to release-3.1 Signed-off-by: sre-bot --- TOC.md | 8 +- reference/tools/user-guide.md | 4 +- .../maintain/backup-and-restore/backup-gcs.md | 206 +++++++++++++ .../maintain/backup-and-restore/backup-s3.md | 273 ++++++++++++++++++ .../charts.md} | 14 +- .../backup-and-restore/restore-gcs.md | 83 ++++++ .../maintain/backup-and-restore/restore-s3.md | 84 ++++++ .../reference/configuration/storage-class.md | 2 +- tidb-in-kubernetes/tidb-operator-overview.md | 2 +- 9 files changed, 668 insertions(+), 8 deletions(-) create mode 100644 tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md create mode 100644 tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md rename tidb-in-kubernetes/maintain/{backup-and-restore.md => backup-and-restore/charts.md} (90%) create mode 100644 tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md create mode 100644 tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md diff --git a/TOC.md b/TOC.md index e9805f7e8335..488d9549e12e 100644 --- a/TOC.md +++ b/TOC.md @@ -382,7 +382,13 @@ + 运维 - [销毁 TiDB 集群](/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md) - [维护 TiDB 集群所在节点](/tidb-in-kubernetes/maintain/kubernetes-node.md) - - [备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore.md) + + 备份与恢复 + - [基于 Helm Charts 的备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) + + 基于 CRD 的备份恢复 + - [备份 TiDB 集群到 GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) + - [恢复 GCS 上的备份数据](/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md) + - [备份 TiDB 集群到兼容 S3 的存储](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md) + - [恢复 S3 兼容存储上的备份数据](/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md) - [恢复 Kubernetes 上的 TiDB 集群数据](/tidb-in-kubernetes/maintain/lightning.md) - [收集日志](/tidb-in-kubernetes/maintain/log-collecting.md) - [集群故障自动转移](/tidb-in-kubernetes/maintain/auto-failover.md) diff --git a/reference/tools/user-guide.md b/reference/tools/user-guide.md index 50ac6988f951..f22da3fb4af4 100644 --- a/reference/tools/user-guide.md +++ b/reference/tools/user-guide.md @@ -28,7 +28,7 @@ TiDB 生态工具可以分为几种： - Loader 的输入：Mydumper 输出的文件 - Loader 的输出：以 SQL 形式写入 TiDB - 适用 TiDB 版本：所有版本 -- Kubernetes 支持：[备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore.md) +- Kubernetes 支持：[备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) #### 全量导入工具 TiDB Lightning @@ -90,7 +90,7 @@ TiDB 生态工具可以分为几种： - Mydumper 的输入：MySQL/TiDB 集群 - Mydumper 的输出：SQL 文件 - 适用 TiDB 版本：所有版本 -- Kubernetes 支持：[备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore.md) +- Kubernetes 支持：[备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) #### 增量导出工具 TiDB Binlog diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md new file mode 100644 index 000000000000..28dc2e1b48cb --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -0,0 +1,206 @@ +--- +title: 备份 TiDB 集群到 GCS +category: how-to +--- + +# 备份 TiDB 集群到 GCS + +本文档详细描述了如何将 Kubernetes 上 TiDB 集群的数据备份到 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份），底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后再将备份数据上传到远端 GCS。 + +本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现的。基于 Helm Charts 的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 + +## Ad-hoc 全量备份 + +Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 `Backup` 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。 + +为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 + +### Ad-hoc 全量备份环境准备 + +1. 下载文件 [backup-rbac.yaml](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并执行以下命令在 `test1` 这个 namespace 中创建备份需要的 RBAC 相关资源： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test1 + ``` + +2. 创建 `gcs-secret` secret。该 secret 存放用于访问 GCS 的凭证。`google-credentials.json` 文件存放用户从 GCP console 上下载的 service account key。具体操作参考 [GCP 官方文档](https://cloud.google.com/docs/authentication/getting-started)。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1 + ``` + +3. 创建 `backup-demo1-tidb-secret` secret。该 secret 存放用于访问 TiDB 集群的 root 账号和密钥。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic backup-demo1-tidb-secret --from-literal=password= --namespace=test1 + ``` + +### 备份数据到 GCS + +创建 `Backup` CR，并将数据备份到 GCS。 + +{{< copyable "shell-regular" >}} + +```shell +kubectl apply -f backup-gcs.yaml +``` + +`backup-gcs.yaml` 文件内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-backup-gcs + namespace: test1 +spec: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + gcs: + secretName: gcs-secret + projectId: + # location: us-east1 + # storageClass: STANDARD_IA + # objectAcl: private + # bucketAcl: private + storageClassName: local-storage + storageSize: 10Gi +``` + +以上示例将 TiDB 集群的数据全量导出备份到 GCS。GCS 配置中的 `location`、`objectAcl`、`bucketAcl`、`storageClass` 项均可以省略。 + +配置中的 `projectId` 代表 GCP 上用户项目的唯一标识。具体获取该标识的方法可参考 [GCP 官方文档](https://cloud.google.com/resource-manager/docs/creating-managing-projects)。 + +GCS 支持以下几种 `storageClass` 类型： + +* `MULTI_REGIONAL` +* `REGIONAL` +* `NEARLINE` +* `COLDLINE` +* `DURABLE_REDUCED_AVAILABILITY` + +如果不设置 `storageClass`，则默认使用 `COLDLINE`。这几种存储类型的详细介绍可参考 [GCS 官方文档](https://cloud.google.com/storage/docs/storage-classes)。 + +GCS 支持以下几种 object ACL 策略： + +* `authenticatedRead` +* `bucketOwnerFullControl` +* `bucketOwnerRead` +* `private` +* `projectPrivate` +* `publicRead` + +如果不设置 object ACL 策略，则默认使用 `private` 策略。这几种访问控制策略的详细介绍可参考 [GCS 官方文档](https://cloud.google.com/storage/docs/access-control/lists)。 + +GCS 支持以下几种 bucket ACL 策略： + +* `authenticatedRead` +* `private` +* `projectPrivate` +* `publicRead` +* `publicReadWrite` + +如果不设置 bucket ACL 策略，则默认策略为 `private`。这几种访问控制策略的详细介绍可参考 [GCS 官方文档](https://cloud.google.com/storage/docs/access-control/lists)。 + +创建好 `Backup` CR 后，可通过以下命令查看备份状态： + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -n test1 -owide + ``` + +更多 `Backup` CR 字段的详细解释： + +* `.spec.metadata.namespace`：`Backup` CR 所在的 namespace。 +* `.spec.from.host`：待备份 TiDB 集群的访问地址。 +* `.spec.from.port`：待备份 TiDB 集群的访问端口。 +* `.spec.from.user`：待备份 TiDB 集群的访问用户。 +* `.spec.from.tidbSecretName`：待备份 TiDB 集群所需凭证的 secret。 +* `.spec.storageClassName`：备份时指定所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 +* `.spec.storageSize`：备份时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。 + +## 定时全量备份 + +用户通过设置备份策略来对 TiDB 集群进行定时备份，同时设置备份的保留策略以避免产生过多的备份。定时全量备份通过自定义的 `BackupSchedule` CR 对象来描述。每到备份时间点会触发一次全量备份，定时全量备份底层通过 Ad-hoc 全量备份来实现。下面是创建定时全量备份的具体步骤： + +### 定时全量备份环境准备 + +同 [Ad-hoc 全量备份环境准备](#ad-hoc-全量备份环境准备)。 + +### 定时全量备份数据到 GCS + +创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 GCS： + +{{< copyable "shell-regular" >}} + +```shell +kubectl apply -f backup-schedule-gcs.yaml +``` + +`backup-schedule-gcs.yaml` 文件内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: BackupSchedule +metadata: + name: demo1-backup-schedule-gcs + namespace: test1 +spec: + #maxBackups: 5 + #pause: true + maxReservedTime: "3h" + schedule: "*/2 * * * *" + backupTemplate: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + gcs: + secretName: gcs-secret + projectId: + # location: us-east1 + # storageClass: STANDARD_IA + # objectAcl: private + # bucketAcl: private + storageClassName: local-storage + storageSize: 10Gi +``` + +定时全量备份创建完成后，可以通过以下命令查看定时全量备份的状态： + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bks -n test1 -owide +``` + +查看定时全量备份下面所有的备份条目： + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-gcs -n test1 + ``` + +从以上示例可知，`backupSchedule` 的配置由两部分组成。一部分是 `backupSchedule` 独有的配置，另一部分是 `backupTemplate`。`backupTemplate` 指定 GCS 存储相关的配置，该配置与 Ad-hoc 全量备份到 GCS 的配置完全一样，可参考[备份数据到 GCS](#备份数据到-gcs)。下面介绍 `backupSchedule` 独有的配置项： + +`.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 + +`.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。比如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考[`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 + +`.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 + +`.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md new file mode 100644 index 000000000000..6a780b81aa05 --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -0,0 +1,273 @@ +--- +title: 备份 TiDB 集群到兼容 S3 的存储 +category: how-to +--- + +# 备份 TiDB 集群到兼容 S3 的存储 + +本文详细描述了如何将 Kubernetes 上的 TiDB 集群数据备份到兼容 S3 的存储上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份）。底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后在将备份数据上传到兼容 S3 的存储上。 + +本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 + +## Ad-hoc 全量备份 + +Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 `Backup` 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。目前兼容 S3 的存储中，Ceph 和 Amazon S3 经测试可正常工作。因此下文对 Ceph 和 Amazon S3 这两种存储的使用进行描述。理论上来说，其余兼容 S3 的存储也可以正常的工作。 + +为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 + +### Ad-hoc 全量备份环境准备 + +1. 下载文件 [backup-rbac.yaml](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并执行以下命令在 `test1` 这个 namespace 中创建备份需要的 RBAC 相关资源： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test1 + ``` + +2. 创建 `s3-secret` secret。该 secret 存放用于访问 S3 兼容存储的凭证。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1 + ``` + +3. 创建 `backup-demo1-tidb-secret` secret。该 secret 存放用于访问 TiDB 集群的 root 账号和密钥。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic backup-demo1-tidb-secret --from-literal=password= --namespace=test1 + ``` + +### 备份数据到兼容 S3 的存储 + +1. 创建 `Backup` CR，并将数据备份到 Amazon S3。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-s3.yaml + ``` + + `backup-s3.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-backup-s3 + namespace: test1 + spec: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + s3: + provider: aws + secretName: s3-secret + # region: us-east-1 + # storageClass: STANDARD_IA + # acl: private + # endpoint: + storageClassName: local-storage + storageSize: 10Gi + ``` + +2. 创建 `Backup` CR，并将数据备份到 Ceph。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-s3.yaml + ``` + + `backup-s3.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-backup-s3 + namespace: test1 + spec: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + s3: + provider: ceph + secretName: s3-secret + endpoint: http://10.0.0.1:30074 + storageClassName: local-storage + storageSize: 10Gi + ``` + +以上两个示例分别将 TiDB 集群的数据全量导出备份到 Amazon S3 和 Ceph 上。Amazon S3 的 `region`、`acl`、`enpoint`、`storageClass` 配置项均可以省略。其余非 Amazon S3 的但是兼容 S3 的存储均可使用和 Amazon S3 类似的配置。可参考上面例子中 Ceph 的配置，省略不需要配置的字段。 + +Amazon S3 支持以下几种 ACL 策略： + +* `private` +* `public-read` +* `public-read-write` +* `authenticated-read` +* `bucket-owner-read` +* `bucket-owner-full-control` + +如果不设置 ACL 策略，则默认使用 `private` 策略。这几种访问控制策略的详细介绍参考 AWS [官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)。 + +Amazon S3 支持以下几种 storageClass 类型： + +* `STANDARD` +* `REDUCED_REDUNDANCY` +* `STANDARD_IA` +* `ONEZONE_IA` +* `GLACIER` +* `DEEP_ARCHIVE` + +如果不设置 `storageClass`，则默认使用 `STANDARD_IA`。这几种存储类型的详细介绍参考 AWS [官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html)。 + +创建好 `Backup` CR 后，可通过如下命令查看备份状态： + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -n test1 -owide + ``` + +更多 `Backup` CR 字段的详细解释: + +* `.spec.metadata.namespace`：`Backup` CR 所在的 namespace。 +* `.spec.from.host`：待备份 TiDB 集群的访问地址。 +* `.spec.from.port`：待备份 TiDB 集群的访问端口。 +* `.spec.from.user`：待备份 TiDB 集群的访问用户。 +* `.spec.from.tidbSecretName`：待备份 TiDB 集群所需凭证的 secret。 +* `.spec.storageClassName`: 备份时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 +* `.spec.storageSize`: 备份时指定所需的 PV 大小。该值须大于备份 TiDB 集群的数据大小。 + +更多支持的兼容 S3 的 `provider` 如下： + +* `alibaba`：Alibaba Cloud Object Storage System (OSS) formerly Aliyun +* `digitalocean`：Digital Ocean Spaces +* `dreamhost`：Dreamhost DreamObjects +* `ibmcos`：IBM COS S3 +* `minio`：Minio Object Storage +* `netease`：Netease Object Storage (NOS) +* `wasabi`：Wasabi Object Storage +* `other`：Any other S3 compatible provider + +## 定时全量备份 + +用户通过设置备份策略来对 TiDB 集群进行定时备份，同时设置备份的保留策略以避免产生过多的备份。定时全量备份通过自定义的 `BackupSchedule` CR 对象来描述。每到备份时间点会触发一次全量备份，定时全量备份底层通过 Ad-hoc 全量备份来实现。下面是创建定时全量备份的具体步骤： + +### 定时全量备份环境准备 + +同 [Ad-hoc 全量备份环境准备](#ad-hoc-全量备份环境准备)。 + +### 定时全量备份数据到 S3 兼容存储 + +1. 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Amazon S3。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-schedule-s3.yaml + ``` + + `backup-schedule-s3.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: BackupSchedule + metadata: + name: demo1-backup-schedule-s3 + namespace: test1 + spec: + #maxBackups: 5 + #pause: true + maxReservedTime: "3h" + schedule: "*/2 * * * *" + backupTemplate: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + s3: + provider: aws + secretName: s3-secret + # region: us-east-1 + # storageClass: STANDARD_IA + # acl: private + # endpoint: + storageClassName: local-storage + storageSize: 10Gi + ``` + +2. 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Ceph。 + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-schedule-s3.yaml + ``` + + `backup-schedule-s3.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: BackupSchedule + metadata: + name: demo1-backup-schedule-ceph + namespace: test1 + spec: + #maxBackups: 5 + #pause: true + maxReservedTime: "3h" + schedule: "*/2 * * * *" + backupTemplate: + from: + host: + port: + user: + secretName: backup-demo1-tidb-secret + s3: + provider: ceph + secretName: s3-secret + endpoint: http://10.0.0.1:30074 + storageClassName: local-storage + storageSize: 10Gi + ``` + +定时全量备份创建完成后，可以通过以下命令查看定时全量备份的状态： + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bks -n test1 -owide +``` + +查看定时全量备份下面所有的备份条目： + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-s3 -n test1 +``` + +从以上两个示例可知，`backupSchedule` 的配置由两部分组成。一部分是 `backupSchedule` 独有的配置，另一部分是 `backupTemplate`。`backupTemplate` 指定 S3 兼容存储相关的配置，该配置与 Ad-hoc 全量备份到兼容 S3 的存储配置完全一样，可参考[备份数据到兼容 S3 的存储](#备份数据到兼容-s3-的存储)。下面介绍 `backupSchedule` 独有的配置项： + +`.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 + +`.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。例如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考 [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 + +`.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 + +`.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore.md b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md similarity index 90% rename from tidb-in-kubernetes/maintain/backup-and-restore.md rename to tidb-in-kubernetes/maintain/backup-and-restore/charts.md index 15b797efac0c..094ee59f79b4 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md @@ -1,11 +1,19 @@ --- -title: Kubernetes 上的 TiDB 集群备份恢复 +title: 基于 Helm Charts 实现的 TiDB 集群备份恢复 category: how-to +aliases: ['/docs-cn/dev/tidb-in-kubernetes/maintain/backup-and-store/'] --- -# Kubernetes 上的 TiDB 集群备份与恢复 +# 基于 Helm Charts 实现的 TiDB 集群备份与恢复 -这篇文档详细描述了如何对 Kubernetes 上的 TiDB 集群进行数据备份和数据恢复。 +本文详细描述了如何对 Kubernetes 上的 TiDB 集群进行数据备份和数据恢复。本文使用的备份恢复方式是基于 Helm Charts 实现的。 + +TiDB Operator 1.1 及以上版本推荐使用基于 CRD 的备份恢复方式实现，详情可参阅以下文档： + +- [备份 TiDB 集群到 GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) +- [恢复 GCS 上的备份数据](/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md) +- [备份 TiDB 集群到兼容 S3 的存储](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md) +- [恢复 S3 兼容存储上的备份数据](/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md) Kubernetes 上的 TiDB 集群支持两种备份策略： diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md new file mode 100644 index 000000000000..fe064398945f --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -0,0 +1,83 @@ +--- +title: 恢复 GCS 上的备份数据 +category: how-to +--- + +# 恢复 GCS 上的备份数据 + +本文详细描述了将 Kubernetes 上通过 TiDB Operator 备份的 TiDB 集群数据恢复的具体操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来进行集群恢复。 + +本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现的。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 + +以下示例将存储在 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上指定路径中的集群备份数据恢复到 TiDB 集群。 + +## 环境准备 + +1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并执行以下命令在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 相关资源： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test2 + ``` + +2. 创建 `restore-demo2-tidb-secret` secret，该 secret 存放用来访问 TiDB 集群的 root 账号和密钥： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 + ``` + +## 将指定备份恢复到 TiDB 集群 + +1. 创建 restore custom resource (CR)，将指定的备份数据恢复至 TiDB 集群： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f restore.yaml + ``` + + `restore.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Restore + metadata: + name: demo2-restore + namespace: test2 + spec: + to: + host: + port: + user: + secretName: restore-demo2-tidb-secret + gcs: + projectId: + secretName: gcs-secret + path: gcs:// + storageClassName: local-storage + storageSize: 1Gi + ``` + +2. 创建好 `Restore` CR 后可通过以下命令查看恢复的状态： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl get rt -n test2 -owide + ``` + +以上示例将存储在 GCS 上指定路径 `spec.gcs.path` 的备份数据恢复到 TiDB 集群 `spec.to.host`。关于 GCS 的配置项可以参考 [backup-gcs.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md#备份数据到-gcs) 中的配置。 + +更多 `Restore` CR 字段的详细解释如下： + +* `.spec.metadata.namespace`： `Restore` CR 所在的 namespace。 +* `.spec.to.host`：待恢复 TiDB 集群的访问地址。 +* `.spec.to.port`：待恢复 TiDB 集群访问的端口。 +* `.spec.to.user`：待恢复 TiDB 集群的访问用户。 +* `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 +* `.spec.storageClassName`：指定恢复时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageSize`：恢复集群时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md new file mode 100644 index 000000000000..1f0caed29447 --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -0,0 +1,84 @@ +--- +title: 恢复 S3 兼容存储上的备份数据 +category: how-to +--- + +# 恢复 S3 兼容存储上的备份数据 + +本文描述了将 Kubernetes 上通过 TiDB Operator 备份的数据恢复到 TiDB 集群的操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来恢复数据。 + +本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 + +以下示例将兼容 S3 的存储（指定路径）上的备份数据恢复到 TiDB 集群。 + +## 环境准备 + +1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 资源，所需命令如下： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test2 + ``` + +2. 创建 `restore-demo2-tidb-secret` secret，该 secret 存放用来访问 TiDB 集群的 root 账号和密钥： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 + ``` + +## 将指定备份恢复到 TiDB 集群 + +1. 创建 restore custom resource (CR)，将指定的备份数据恢复至 TiDB 集群： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f restore.yaml + ``` + + `restore.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Restore + metadata: + name: demo2-restore + namespace: test2 + spec: + to: + host: + port: + user: + secretName: restore-demo2-tidb-secret + s3: + provider: ceph + endpoint: http://10.233.2.161 + secretName: ceph-secret + path: s3:// + storageClassName: local-storage + storageSize: 1Gi + ``` + +2. 创建好 `Restore` CR 后可通过以下命令查看恢复的状态： + + {{< copyable "shell-regular" >}} + + ```shell + kubectl get rt -n test2 -owide + ``` + +以上示例将兼容 S3 的存储（`spec.s3.path` 路径下）中的备份数据恢复到 TiDB 集群 (`spec.to.host`)。有关兼容 S3 的存储的配置项，可以参考 [backup-s3.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md#备份数据到兼容-s3-的存储)。 + +更多 `Restore` CR 字段的详细解释： + +* `.spec.metadata.namespace`：`Restore` CR 所在的 namespace。 +* `.spec.to.host`：待恢复 TiDB 集群的访问地址。 +* `.spec.to.port`：待恢复 TiDB 集群的访问端口。 +* `.spec.to.user`：待恢复 TiDB 集群的访问用户。 +* `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 +* `.spec.storageClassName`：指定恢复时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageSize`：指定恢复集群时所需的 PV 大小。该值应大于备份 TiDB 集群的数据大小。 diff --git a/tidb-in-kubernetes/reference/configuration/storage-class.md b/tidb-in-kubernetes/reference/configuration/storage-class.md index 9e028a10bb72..738be10f779e 100644 --- a/tidb-in-kubernetes/reference/configuration/storage-class.md +++ b/tidb-in-kubernetes/reference/configuration/storage-class.md @@ -112,7 +112,7 @@ Kubernetes 当前支持静态分配的本地存储。可使用 [local-static-pro > **注意：** > - > 该步骤中创建的目录个数取决于规划的 TiDB 集群数量、每个集群内的 Pump 数量及备份方式。1 个目录会对应创建 1 个 PV。每个 Pump 会使用 1 个 PV，每个 drainer 会使用 1 个 PV，每次 [Ad-hoc 全量备份](/tidb-in-kubernetes/maintain/backup-and-restore.md#ad-hoc-全量备份)会使用 1 个 PV，所有[定时全量备份](/tidb-in-kubernetes/maintain/backup-and-restore.md#定时全量备份)会共用 1 个 PV。 + > 该步骤中创建的目录个数取决于规划的 TiDB 集群数量、每个集群内的 Pump 数量及备份方式。1 个目录会对应创建 1 个 PV。每个 Pump 会使用 1 个 PV，每个 drainer 会使用 1 个 PV，每次 [Ad-hoc 全量备份](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md#ad-hoc-全量备份)会使用 1 个 PV，所有[定时全量备份](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md#定时全量备份)会共用 1 个 PV。 - 给 PD 数据使用的盘，可以参考[步骤](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs)挂载盘，创建目录，并将新建的目录以 bind mount 方式挂载到 `/mnt/sharedssd` 目录，后续创建 `shared-ssd-storage` `StorageClass`。 diff --git a/tidb-in-kubernetes/tidb-operator-overview.md b/tidb-in-kubernetes/tidb-operator-overview.md index 56e94a4f8061..911235dac9bb 100644 --- a/tidb-in-kubernetes/tidb-operator-overview.md +++ b/tidb-in-kubernetes/tidb-operator-overview.md @@ -57,7 +57,7 @@ TiDB Operator 提供了多种方式来部署 Kubernetes 上的 TiDB 集群： + [TiDB 集群扩缩容](/tidb-in-kubernetes/scale-in-kubernetes.md) + [TiDB 集群升级](/tidb-in-kubernetes/upgrade/tidb-cluster.md#升级-tidb-版本) + [TiDB 集群配置变更](/tidb-in-kubernetes/upgrade/tidb-cluster.md#更新-tidb-集群配置) -+ [TiDB 集群备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore.md) ++ [TiDB 集群备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) + [配置 TiDB 集群故障自动转移](/tidb-in-kubernetes/maintain/auto-failover.md) + [监控 TiDB 集群](/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md) + [TiDB 集群日志收集](/tidb-in-kubernetes/maintain/log-collecting.md) From 014cf23b0a2d1fba7e2db3b596025a297c0b2508 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 28 Feb 2020 20:12:58 +0800 Subject: [PATCH 2/4] address comment Co-Authored-By: Keke Yi <40977455+yikeke@users.noreply.github.com> --- tidb-in-kubernetes/maintain/backup-and-restore/charts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md index 094ee59f79b4..de2a90373afe 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md @@ -1,7 +1,7 @@ --- title: 基于 Helm Charts 实现的 TiDB 集群备份恢复 category: how-to -aliases: ['/docs-cn/dev/tidb-in-kubernetes/maintain/backup-and-store/'] +aliases: ['/docs-cn/v3.1/tidb-in-kubernetes/maintain/backup-and-store/'] --- # 基于 Helm Charts 实现的 TiDB 集群备份与恢复 From 21184fa4d46cd0b072b2cd0f7831858b5100a220 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 4 Mar 2020 17:32:54 +0800 Subject: [PATCH 3/4] refine format and wording --- .../maintain/backup-and-restore/backup-gcs.md | 17 +++++----- .../maintain/backup-and-restore/backup-s3.md | 31 +++++++++---------- .../backup-and-restore/restore-gcs.md | 8 ++--- .../maintain/backup-and-restore/restore-s3.md | 8 ++--- 4 files changed, 29 insertions(+), 35 deletions(-) diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md index 28dc2e1b48cb..14e4bd3f3072 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -7,7 +7,7 @@ category: how-to 本文档详细描述了如何将 Kubernetes 上 TiDB 集群的数据备份到 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份），底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后再将备份数据上传到远端 GCS。 -本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现的。基于 Helm Charts 的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现的。基于 Helm Charts 的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 ## Ad-hoc 全量备份 @@ -91,7 +91,7 @@ GCS 支持以下几种 `storageClass` 类型： 如果不设置 `storageClass`，则默认使用 `COLDLINE`。这几种存储类型的详细介绍可参考 [GCS 官方文档](https://cloud.google.com/storage/docs/storage-classes)。 -GCS 支持以下几种 object ACL 策略： +GCS 支持以下几种 object access control list (ACL) 策略： * `authenticatedRead` * `bucketOwnerFullControl` @@ -127,7 +127,7 @@ GCS 支持以下几种 bucket ACL 策略： * `.spec.from.port`：待备份 TiDB 集群的访问端口。 * `.spec.from.user`：待备份 TiDB 集群的访问用户。 * `.spec.from.tidbSecretName`：待备份 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`：备份时指定所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 +* `.spec.storageClassName`：备份时指定所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 * `.spec.storageSize`：备份时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。 ## 定时全量备份 @@ -197,10 +197,7 @@ kubectl get bks -n test1 -owide 从以上示例可知，`backupSchedule` 的配置由两部分组成。一部分是 `backupSchedule` 独有的配置，另一部分是 `backupTemplate`。`backupTemplate` 指定 GCS 存储相关的配置，该配置与 Ad-hoc 全量备份到 GCS 的配置完全一样，可参考[备份数据到 GCS](#备份数据到-gcs)。下面介绍 `backupSchedule` 独有的配置项： -`.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 - -`.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。比如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考[`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 - -`.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 - -`.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 ++ `.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 ++ `.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。比如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考[`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 ++ `.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 ++ `.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md index 6a780b81aa05..0977c100f26b 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -7,13 +7,13 @@ category: how-to 本文详细描述了如何将 Kubernetes 上的 TiDB 集群数据备份到兼容 S3 的存储上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份）。底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后在将备份数据上传到兼容 S3 的存储上。 -本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 ## Ad-hoc 全量备份 -Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 `Backup` 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。目前兼容 S3 的存储中，Ceph 和 Amazon S3 经测试可正常工作。因此下文对 Ceph 和 Amazon S3 这两种存储的使用进行描述。理论上来说，其余兼容 S3 的存储也可以正常的工作。 +Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 `Backup` 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。 -为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 +目前兼容 S3 的存储中，Ceph 和 Amazon S3 经测试可正常工作。下文对 Ceph 和 Amazon S3 这两种存储的使用进行描述。为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 ### Ad-hoc 全量备份环境准备 @@ -43,7 +43,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) ### 备份数据到兼容 S3 的存储 -1. 创建 `Backup` CR，并将数据备份到 Amazon S3。 ++ 创建 `Backup` CR，并将数据备份到 Amazon S3。 {{< copyable "shell-regular" >}} @@ -77,7 +77,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) storageSize: 10Gi ``` -2. 创建 `Backup` CR，并将数据备份到 Ceph。 ++ 创建 `Backup` CR，并将数据备份到 Ceph。 {{< copyable "shell-regular" >}} @@ -108,9 +108,9 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) storageSize: 10Gi ``` -以上两个示例分别将 TiDB 集群的数据全量导出备份到 Amazon S3 和 Ceph 上。Amazon S3 的 `region`、`acl`、`enpoint`、`storageClass` 配置项均可以省略。其余非 Amazon S3 的但是兼容 S3 的存储均可使用和 Amazon S3 类似的配置。可参考上面例子中 Ceph 的配置，省略不需要配置的字段。 +以上两个示例分别将 TiDB 集群的数据全量导出备份到 Amazon S3 和 Ceph 上。Amazon S3 的 `region`、`acl`、`endpoint`、`storageClass` 配置项均可以省略。其余非 Amazon S3 的但是兼容 S3 的存储均可使用和 Amazon S3 类似的配置。可参考上面例子中 Ceph 的配置，省略不需要配置的字段。 -Amazon S3 支持以下几种 ACL 策略： +Amazon S3 支持以下几种 object access control list (ACL) 策略： * `private` * `public-read` @@ -147,7 +147,7 @@ Amazon S3 支持以下几种 storageClass 类型： * `.spec.from.port`：待备份 TiDB 集群的访问端口。 * `.spec.from.user`：待备份 TiDB 集群的访问用户。 * `.spec.from.tidbSecretName`：待备份 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`: 备份时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 +* `.spec.storageClassName`: 备份时所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值，该值默认为 `standard`。 * `.spec.storageSize`: 备份时指定所需的 PV 大小。该值须大于备份 TiDB 集群的数据大小。 更多支持的兼容 S3 的 `provider` 如下： @@ -171,7 +171,7 @@ Amazon S3 支持以下几种 storageClass 类型： ### 定时全量备份数据到 S3 兼容存储 -1. 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Amazon S3。 ++ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Amazon S3。 {{< copyable "shell-regular" >}} @@ -210,7 +210,7 @@ Amazon S3 支持以下几种 storageClass 类型： storageSize: 10Gi ``` -2. 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Ceph。 ++ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Ceph。 {{< copyable "shell-regular" >}} @@ -264,10 +264,7 @@ kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-s3 -n t 从以上两个示例可知，`backupSchedule` 的配置由两部分组成。一部分是 `backupSchedule` 独有的配置，另一部分是 `backupTemplate`。`backupTemplate` 指定 S3 兼容存储相关的配置，该配置与 Ad-hoc 全量备份到兼容 S3 的存储配置完全一样，可参考[备份数据到兼容 S3 的存储](#备份数据到兼容-s3-的存储)。下面介绍 `backupSchedule` 独有的配置项： -`.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 - -`.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。例如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考 [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 - -`.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 - -`.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 ++ `.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 ++ `.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。例如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考 [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 ++ `.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 ++ `.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md index fe064398945f..90333a5d024f 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -7,13 +7,13 @@ category: how-to 本文详细描述了将 Kubernetes 上通过 TiDB Operator 备份的 TiDB 集群数据恢复的具体操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来进行集群恢复。 -本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现的。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现的。基于 Helm Charts 实现的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 以下示例将存储在 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上指定路径中的集群备份数据恢复到 TiDB 集群。 ## 环境准备 -1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并执行以下命令在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 相关资源： +1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并执行以下命令在 `test2` 这个 namespace 中创建恢复所需的 RBAC 相关资源： {{< copyable "shell-regular" >}} @@ -29,7 +29,7 @@ category: how-to kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 ``` -## 将指定备份恢复到 TiDB 集群 +## 将指定备份数据恢复到 TiDB 集群 1. 创建 restore custom resource (CR)，将指定的备份数据恢复至 TiDB 集群： @@ -79,5 +79,5 @@ category: how-to * `.spec.to.port`：待恢复 TiDB 集群访问的端口。 * `.spec.to.user`：待恢复 TiDB 集群的访问用户。 * `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`：指定恢复时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageClassName`：指定恢复时所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 * `.spec.storageSize`：恢复集群时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md index 1f0caed29447..eebb885c8253 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -7,13 +7,13 @@ category: how-to 本文描述了将 Kubernetes 上通过 TiDB Operator 备份的数据恢复到 TiDB 集群的操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来恢复数据。 -本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CRD 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 实现的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 以下示例将兼容 S3 的存储（指定路径）上的备份数据恢复到 TiDB 集群。 ## 环境准备 -1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 资源，所需命令如下： +1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并在 `test2` 这个 namespace 中创建恢复所需的 RBAC 资源，所需命令如下： {{< copyable "shell-regular" >}} @@ -29,7 +29,7 @@ category: how-to kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 ``` -## 将指定备份恢复到 TiDB 集群 +## 将指定备份数据恢复到 TiDB 集群 1. 创建 restore custom resource (CR)，将指定的备份数据恢复至 TiDB 集群： @@ -80,5 +80,5 @@ category: how-to * `.spec.to.port`：待恢复 TiDB 集群的访问端口。 * `.spec.to.user`：待恢复 TiDB 集群的访问用户。 * `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`：指定恢复时所需的 PV 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageClassName`：指定恢复时所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 * `.spec.storageSize`：指定恢复集群时所需的 PV 大小。该值应大于备份 TiDB 集群的数据大小。 From 77aca44aa5fcbb6bafe0016f539afd8f7968c1f1 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Thu, 5 Mar 2020 15:12:48 +0800 Subject: [PATCH 4/4] refine language --- .../maintain/backup-and-restore/backup-gcs.md | 8 ++++---- .../maintain/backup-and-restore/backup-s3.md | 20 +++++++++---------- .../maintain/backup-and-restore/charts.md | 4 ++-- .../backup-and-restore/restore-gcs.md | 8 ++++---- .../maintain/backup-and-restore/restore-s3.md | 2 +- 5 files changed, 21 insertions(+), 21 deletions(-) diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md index 14e4bd3f3072..717d4efca0d3 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -7,7 +7,7 @@ category: how-to 本文档详细描述了如何将 Kubernetes 上 TiDB 集群的数据备份到 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份），底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后再将备份数据上传到远端 GCS。 -本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现的。基于 Helm Charts 的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 ## Ad-hoc 全量备份 @@ -43,7 +43,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) ### 备份数据到 GCS -创建 `Backup` CR，并将数据备份到 GCS。 +创建 `Backup` CR，并将数据备份到 GCS： {{< copyable "shell-regular" >}} @@ -91,7 +91,7 @@ GCS 支持以下几种 `storageClass` 类型： 如果不设置 `storageClass`，则默认使用 `COLDLINE`。这几种存储类型的详细介绍可参考 [GCS 官方文档](https://cloud.google.com/storage/docs/storage-classes)。 -GCS 支持以下几种 object access control list (ACL) 策略： +GCS 支持以下几种 object access-control list (ACL) 策略： * `authenticatedRead` * `bucketOwnerFullControl` @@ -200,4 +200,4 @@ kubectl get bks -n test1 -owide + `.spec.maxBackups`：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 `0`，则表示保留所有备份。 + `.spec.maxReservedTime`：一种备份保留策略，按时间保留备份。比如将该参数设置为 `24h`，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考[`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration)。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。 + `.spec.schedule`：Cron 的时间调度格式。具体格式可参考 [Cron](https://en.wikipedia.org/wiki/Cron)。 -+ `.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 ++ `.spec.pause`：该值默认为 `false`。如果将该值设置为 `true`，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 [Garbage Collection (GC)](/reference/garbage-collection/overview.md) 仍然正常进行。将 `true` 改为 `false` 则重新开启定时全量备份。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md index 0977c100f26b..afc1e404abe1 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -7,13 +7,13 @@ category: how-to 本文详细描述了如何将 Kubernetes 上的 TiDB 集群数据备份到兼容 S3 的存储上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份）。底层通过使用 [`mydumper`](/reference/tools/mydumper.md) 获取集群的逻辑备份，然后在将备份数据上传到兼容 S3 的存储上。 -本文使用的备份恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 实现的备份恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 实现的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 ## Ad-hoc 全量备份 Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 `Backup` 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。 -目前兼容 S3 的存储中，Ceph 和 Amazon S3 经测试可正常工作。下文对 Ceph 和 Amazon S3 这两种存储的使用进行描述。为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 +目前兼容 S3 的存储中，Ceph 和 Amazon S3 经测试可正常工作。下文对 Ceph 和 Amazon S3 这两种存储的使用进行描述。本文档提供如下备份示例。示例假设对部署在 Kubernetes `test1` 这个 namespace 中的 TiDB 集群 `demo1` 进行数据备份，下面是具体操作过程。 ### Ad-hoc 全量备份环境准备 @@ -43,7 +43,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) ### 备份数据到兼容 S3 的存储 -+ 创建 `Backup` CR，并将数据备份到 Amazon S3。 ++ 创建 `Backup` CR，并将数据备份到 Amazon S3： {{< copyable "shell-regular" >}} @@ -77,7 +77,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) storageSize: 10Gi ``` -+ 创建 `Backup` CR，并将数据备份到 Ceph。 ++ 创建 `Backup` CR，并将数据备份到 Ceph： {{< copyable "shell-regular" >}} @@ -110,7 +110,7 @@ Ad-hoc 全量备份通过创建一个自定义的 `Backup` custom resource (CR) 以上两个示例分别将 TiDB 集群的数据全量导出备份到 Amazon S3 和 Ceph 上。Amazon S3 的 `region`、`acl`、`endpoint`、`storageClass` 配置项均可以省略。其余非 Amazon S3 的但是兼容 S3 的存储均可使用和 Amazon S3 类似的配置。可参考上面例子中 Ceph 的配置，省略不需要配置的字段。 -Amazon S3 支持以下几种 object access control list (ACL) 策略： +Amazon S3 支持以下几种 access-control list (ACL) 策略： * `private` * `public-read` @@ -119,9 +119,9 @@ Amazon S3 支持以下几种 object access control list (ACL) 策略： * `bucket-owner-read` * `bucket-owner-full-control` -如果不设置 ACL 策略，则默认使用 `private` 策略。这几种访问控制策略的详细介绍参考 AWS [官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)。 +如果不设置 ACL 策略，则默认使用 `private` 策略。这几种访问控制策略的详细介绍参考 [AWS 官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)。 -Amazon S3 支持以下几种 storageClass 类型： +Amazon S3 支持以下几种 `storageClass` 类型： * `STANDARD` * `REDUCED_REDUNDANCY` @@ -130,7 +130,7 @@ Amazon S3 支持以下几种 storageClass 类型： * `GLACIER` * `DEEP_ARCHIVE` -如果不设置 `storageClass`，则默认使用 `STANDARD_IA`。这几种存储类型的详细介绍参考 AWS [官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html)。 +如果不设置 `storageClass`，则默认使用 `STANDARD_IA`。这几种存储类型的详细介绍参考 [AWS 官方文档](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html)。 创建好 `Backup` CR 后，可通过如下命令查看备份状态： @@ -171,7 +171,7 @@ Amazon S3 支持以下几种 storageClass 类型： ### 定时全量备份数据到 S3 兼容存储 -+ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Amazon S3。 ++ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Amazon S3： {{< copyable "shell-regular" >}} @@ -210,7 +210,7 @@ Amazon S3 支持以下几种 storageClass 类型： storageSize: 10Gi ``` -+ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Ceph。 ++ 创建 `BackupSchedule` CR 开启 TiDB 集群的定时全量备份，将数据备份到 Ceph： {{< copyable "shell-regular" >}} diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md index de2a90373afe..4bf57c0558cc 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md @@ -6,9 +6,9 @@ aliases: ['/docs-cn/v3.1/tidb-in-kubernetes/maintain/backup-and-store/'] # 基于 Helm Charts 实现的 TiDB 集群备份与恢复 -本文详细描述了如何对 Kubernetes 上的 TiDB 集群进行数据备份和数据恢复。本文使用的备份恢复方式是基于 Helm Charts 实现的。 +本文详细描述了如何对 Kubernetes 上的 TiDB 集群进行数据备份和数据恢复。本文使用的备份和恢复方式是基于 Helm Charts 实现的。 -TiDB Operator 1.1 及以上版本推荐使用基于 CRD 的备份恢复方式实现，详情可参阅以下文档： +TiDB Operator 1.1 及以上版本推荐使用基于 CRD 的实现的备份和恢复方式，详情可参阅以下文档： - [备份 TiDB 集群到 GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) - [恢复 GCS 上的备份数据](/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md) diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md index 90333a5d024f..33d559441c05 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -5,11 +5,11 @@ category: how-to # 恢复 GCS 上的备份数据 -本文详细描述了将 Kubernetes 上通过 TiDB Operator 备份的 TiDB 集群数据恢复的具体操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来进行集群恢复。 +本文描述了将 Kubernetes 上通过 TiDB Operator 备份的数据恢复到 TiDB 集群的操作过程。底层通过使用 [`loader`](/reference/tools/loader.md) 来进行集群恢复。 -本文使用的恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现的。基于 Helm Charts 实现的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 +本文使用的恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 实现的备份和恢复方式可参考[基于 Helm Charts 实现的 TiDB 集群备份与恢复](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md)。 -以下示例将存储在 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上指定路径中的集群备份数据恢复到 TiDB 集群。 +以下示例将存储在 [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) 上指定路径上的集群备份数据恢复到 TiDB 集群。 ## 环境准备 @@ -79,5 +79,5 @@ category: how-to * `.spec.to.port`：待恢复 TiDB 集群访问的端口。 * `.spec.to.user`：待恢复 TiDB 集群的访问用户。 * `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`：指定恢复时所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageClassName`：指定恢复时所需的 Persistent Volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 * `.spec.storageSize`：恢复集群时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。 diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md index eebb885c8253..4bcc71f7bcc9 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -80,5 +80,5 @@ category: how-to * `.spec.to.port`：待恢复 TiDB 集群的访问端口。 * `.spec.to.user`：待恢复 TiDB 集群的访问用户。 * `.spec.to.tidbSecretName`：待恢复 TiDB 集群所需凭证的 secret。 -* `.spec.storageClassName`：指定恢复时所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 +* `.spec.storageClassName`：指定恢复时所需的 Persistent Volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 `default-backup-storage-class-name` 指定的值（默认为 `standard`）。 * `.spec.storageSize`：指定恢复集群时所需的 PV 大小。该值应大于备份 TiDB 集群的数据大小。