From 8aaeecbd4a8b05a7e5a47d699f5750e70a15fa21 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 4 Mar 2020 20:34:24 +0800 Subject: [PATCH 1/4] tidb-in-kubernetes: update backup & restore usage docs --- TOC.md | 8 +- .../maintain/backup-and-restore/backup-gcs.md | 204 +++++++++++++ .../maintain/backup-and-restore/backup-s3.md | 273 ++++++++++++++++++ .../charts.md} | 16 +- .../backup-and-restore/restore-gcs.md | 84 ++++++ .../maintain/backup-and-restore/restore-s3.md | 101 +++++++ .../reference/configuration/storage-class.md | 2 +- tidb-in-kubernetes/tidb-operator-overview.md | 2 +- 8 files changed, 683 insertions(+), 7 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 458251a7ce2f0..0a1e94794805b 100644 --- a/TOC.md +++ b/TOC.md @@ -398,7 +398,13 @@ + Maintain - [Destroy a TiDB cluster](/tidb-in-kubernetes/maintain/destroy-tidb-cluster.md) - [Maintain a Hosting Kubernetes Node](/tidb-in-kubernetes/maintain/kubernetes-node.md) - - [Backup and Restore](/tidb-in-kubernetes/maintain/backup-and-restore.md) + + Backup and Restore + - [Helm Charts-Based Backup and Restoration](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) + + CRD-Based Backup and Restoration + - [Back up TiDB Cluster Data to GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) + - [Restore Data From GCS](/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md) + - [Back up TiDB Cluster Data to S3-Compatible Storage](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md) + - [Restore Data From S3-Compatible Storage](/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md) - [Restore Data with TiDB Lightning](/tidb-in-kubernetes/maintain/lightning.md) - [Collect Logs](/tidb-in-kubernetes/maintain/log-collecting.md) - [Automatic Failover](/tidb-in-kubernetes/maintain/auto-failover.md) 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 0000000000000..1cdcbce5104fc --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -0,0 +1,204 @@ +--- +title: Back up TiDB Cluster Data to GCS +summary: Learn how to back up the TiDB cluster to GCS. +category: how-to +--- + +# Back up TiDB Cluster Data to GCS + +This document describes how to back up data of the TiDB cluster in Kubernetes to [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/). "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the remote GCS. + +The backup method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the backup method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). + +## Ad-hoc full backup to GCS + +Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. + +To better explain how to perform the backup operation to GCS, this document shows a use case which backs up data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace. + +### Prerequisites for ad-hoc backup + +1. Download [backup-rbac.yaml](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml) and execute the following command to create the role-based access control (RBAC) resources in the `test1` namespace: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test1 + ``` + +2. Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the GCP console. Refer to [GCP documentation](https://cloud.google.com/docs/authentication/getting-started) for details. + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1 + ``` + +3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic backup-demo1-tidb-secret --from-literal=password= --namespace=test1 + ``` + +### Ad-hoc backup process + +Create the `Backup` CR and back up data to GSC: + +{{< copyable "shell-regular" >}} + +```shell +kubectl apply -f backup-gcs.yaml +``` + +The `backup-gcs.yaml` file has the following content: + +```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 +``` + +The above case exports and backs up all data of the TiDB cluster to GCS. You can ignore the `location`, `objectAcl`, `bucketAcl`, and `storageClass` items in the GCS configuration. + +`projectId` in the configuration is the unique identifier of the user project on GCP. To learn how to get this identifier, refer to the [GCP documentation](https://cloud.google.com/resource-manager/docs/creating-managing-projects). + +GCS supports the following `storageClass` types: + +* `MULTI_REGIONAL` +* `REGIONAL` +* `NEARLINE` +* `COLDLINE` +* `DURABLE_REDUCED_AVAILABILITY` + +If `storageClass` is not configured, `COLDLINE` is used by default. For the detailed description of these storage types, refer to [GCS documentation](https://cloud.google.com/storage/docs/storage-classes). + +GCS supports the following object access control list (ACL) polices: + +* `authenticatedRead` +* `bucketOwnerFullControl` +* `bucketOwnerRead` +* `private` +* `projectPrivate` +* `publicRead` + +If the object ACL policy is not configured, the `private` policy is used by default. For the detailed description of these access control policies, refer to [GCS documentation](https://cloud.google.com/storage/docs/access-control/lists). + +GCS supports the following bucket ACL policies: + +* `authenticatedRead` +* `private` +* `projectPrivate` +* `publicRead` +* `publicReadWrite` + +If the bucket ACL policy is not configured, the `private` policy is used by default. For the detailed description of these access control policies, refer to [GCS documentation](https://cloud.google.com/storage/docs/access-control/lists). + +After creating the `Backup` CR, use the following command to check the backup status: + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -n test1 -owide + ``` + +More `Backup` CRs are as described follows: + +* `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. +* `.spec.from.host`: the accessing address of the TiDB cluster to be backed up. +* `.spec.from.port`: the accessing port of the TiDB cluster to be backed up. +* `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be backed up. +* `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. +* `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. + +## Scheduled full backup to GCS + +You can set a backup policy to perform scheduled backups of the TiDB cluster, and set a backup retention policy to avoid excessive backup items. A scheduled full backup is described by a custom `BackupSchedule` CR object. A full backup is triggered at each backup time point. Its underlying implementation is the ad-hoc full backup. + +### Prerequisites for scheduled backup + +See the [Prerequisites for the ad-hoc backup](#prerequisites-for-ad-hoc-backup). + +### scheduled backup process + +Create the `BackupSchedule` CR to enable the scheduled full backup to GCS: + +{{< copyable "shell-regular" >}} + +```shell +kubectl apply -f backup-schedule-gcs.yaml +``` + +The `backup-gcs.yaml` file has the following content: + +```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 +``` + +After creating the scheduled full backup, use the following command to check the backup status: + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bks -n test1 -owide +``` + +Execute the following command to check all the backup items: + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-gcs -n test1 + ``` + +From the above case, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the GCS storage, which is the same with the configurations for the ad-hoc full backup to GCS (refer to [GCS backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: + ++ `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. ++ `.spec.maxReservedTime`: a backup retention policy based on the time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the format of the time, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting prevails. ++ `.spec.schedule`: the time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. ++ `.spec.pause`: `false` by default. If this parameter is set to `true`, the scheduled scheduling is paused. In this situation, the backup operation will not be performed even if the scheduling time is reached. During this pause, the backup [Garbage Collection](/reference/garbage-collection/overview.md) (GC) runs normally. If you change `true` to `false`, the full backup process is restarted. 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 0000000000000..2b5010b2012e6 --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -0,0 +1,273 @@ +--- +title: Back up TiDB Cluster Data to S3-Compatible Storage +summary: Learn how to back up the TiDB cluster to the S3-compatible storage. +category: how-to +--- + +# Back up TiDB Cluster Data to S3-Compatible Storage + +This document describes how to back up data of the TiDB cluster in Kubernetes to the S3-compatible storage. "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the S3-compatible storage. + +The backup method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the backup method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). + +## Ad-hoc full backup + +Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. + +For the current S3-compatible storages, Ceph and Amazon S3 work normally as tested. Therefore, this document shows use cases which back up data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace to Ceph and Amazon S3 respectively. + +### Prerequisites for ad-hoc backup + +1. Download [backup-rbac.yaml](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml) and execute the following command to create the role-based access control (RBAC) resources in the `test1` namespace: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test1 + ``` + +2. Create the `s3-secret` secret which stores the credential used to access the S3-compatible storage. + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1 + ``` + +3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic backup-demo1-tidb-secret --from-literal=password= --namespace=test1 + ``` + +### Ad-hoc backup process + ++ Create the `Backup` CR and back up data to Amazon S3: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-s3.yaml + ``` + + The `backup-s3.yaml` file has the following content: + + ```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 + ``` + ++ Create the `Backup` CR and back up data to Ceph: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-s3.yaml + ``` + + The `backup-s3.yaml` file has the following content: + + ```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 + ``` + +The above two cases export and back up all data of the TiDB cluster to Amazon S3 and Ceph respectively. You can ignore the `region`, `acl`, `endpoint`, and `storageClass` configuration items in the Amazon S3 configuration. You can also leave empty the configuration item fields if you do not need to configure these items as shown in the above Ceph configuration. + +Amazon S3 supports the following access control list (ACL) polices: + +* `private` +* `public-read` +* `public-read-write` +* `authenticated-read` +* `bucket-owner-read` +* `bucket-owner-full-control` + +If the ACL policy is not configured, the `private` policy is used by default. For the detailed description of these access control policies, refer to [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html). + +Amazon S3 supports the following `storageClass` types: + +* `STANDARD` +* `REDUCED_REDUNDANCY` +* `STANDARD_IA` +* `ONEZONE_IA` +* `GLACIER` +* `DEEP_ARCHIVE` + +If `storageClass` is not configured, `STANDARD_IA` is used by default. For the detailed description of these storage types, refer to [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html). + +After creating the `Backup` CR, use the following command to check the backup status: + +{{< copyable "shell-regular" >}} + + ```shell + kubectl get bk -n test1 -owide + ``` + +More `Backup` CRs are as described follows: + +* `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. +* `.spec.from.host`: the accessing address of the TiDB cluster to be backed up. +* `.spec.from.port`: the accessing port of the TiDB cluster to be backed up. +* `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be backed up. +* `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. +* `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. + +More S3-compatible `provider`s are described as follows: + +* `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 + +## Scheduled full backup to S3-compatible storage + +You can set a backup policy to perform scheduled backups of the TiDB cluster, and set a backup retention policy to avoid excessive backup items. A scheduled full backup is described by a custom `BackupSchedule` CR object. A full backup is triggered at each backup time point. Its underlying implementation is the ad-hoc full backup. + +### Prerequisites for scheduled backup + +同 [Ad-hoc 全量备份环境准备](#ad-hoc-全量备份环境准备)。 + +See [Prerequisites for ad-hoc backup](#prerequisites-for-ad-hoc-backup) + +### Scheduled backup process + ++ Create the `BackupSchedule` CR to enable the scheduled full backup to Amazon S3: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-schedule-s3.yaml + ``` + + The `backup-gcs.yaml` file has the following content: + + ```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 + ``` + ++ Create the `BackupSchedule` CR to enable the scheduled full backup to Amazon S3: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-schedule-s3.yaml + ``` + + The `backup-gcs.yaml` file has the following content: + + ```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 + ``` + +After creating the scheduled full backup, use the following command to check the backup status: + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bks -n test1 -owide +``` + +Execute the followinsg command to check all the backup items: + +{{< copyable "shell-regular" >}} + +```shell +kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-s3 -n test1 +``` + +From the above example, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the S3-compatible storage, which is the same with the configurations for the ad-hoc full backup to the S3-compatible storage (refer to [Ad-hoc backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: + ++ `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. ++ `.spec.maxReservedTime`: a backup retention policy based on the time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the format of the time, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting prevails. ++ `.spec.schedule`: the time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. ++ `.spec.pause`: `false` by default. If this parameter is set to `true`, the scheduled scheduling is paused. In this situation, the backup operation will not be performed even if the scheduling time is reached. During this pause, the backup [Garbage Collection](/reference/garbage-collection/overview.md) (GC) runs normally. If you change `true` to `false`, the full backup process is restarted. 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 0814ea80a718a..1507627b7cc9c 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md @@ -1,12 +1,20 @@ --- -title: Backup and Restore -summary: Learn how to back up and restore the data of TiDB cluster in Kubernetes. +title: Helm Charts-Based Backup and Restoration in Kubernetes +summary: Learn how to back up and restore the data of TiDB cluster in Kubernetes based on Helm Charts. category: how-to +aliases: ['/docs/dev/tidb-in-kubernetes/maintain/backup-and-store/'] --- -# Backup and Restore +# Helm Charts-Based Backup and Restoration in Kubernetes -This document describes how to back up and restore the data of a TiDB cluster in Kubernetes. +This document describes how to back up and restore the data of a TiDB cluster in Kubernetes based on Helm Charts. + +For TiDB Operator 1.1 or later versions, it is recommended that you back up and restore the data of TiDB in Kubernetes based on CustomResourceDefinition (CRD). Refer to the following documents for details: + +- [Back up TiDB Cluster Data to GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) +- [Restore Data From GCS](/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md) +- [Back up TiDB Cluster Data to S3-Compatible Storage](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md) +- [Restore Data From S3-Compatible Storage](/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md) TiDB in Kubernetes supports two kinds of backup strategies: 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 0000000000000..889c528b835bc --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -0,0 +1,84 @@ +--- +title: Restore Data From GCS +summary: Learn how to restore the backup data from GCS. +category: how-to +--- + +# Restore Data From GCS + +This document describes how to restore the TiDB cluster data backed up by TiDB Operator in Kubernetes For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. + +The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). + +This document shows a use case in which the backup data stored in the specified path on [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) is restored to the TiDB cluster. + +## Prerequisites + +1. Download [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml) and execute the following command to create the role-based access control (RBAC) resources in the `test2` namespace: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test2 + ```： + +2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 + ``` + +## Restoration process + +1. Create the restore custom resource (CR) and restore the backup data to the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f restore.yaml + ``` + + The `restore.yaml` file has the following content: + + ```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. After creating the `Restore` CR, execute the following command to check the restoration status: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl get rt -n test2 -owide + ``` + +The above case restores the backup data stored in the specified `spec.gcs.path` path on GCS to the `spec.to.host` TiDB cluster. For the configuration of GCS, refer to [backup-gcs.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md#ad-hoc-backup-process). + +More `Restore` CRs are as described follows: + +* `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. +* `.spec.to.host`: the accessing address of the TiDB cluster to be restored. +* `.spec.to.port`: the accessing port of the TiDB cluster to be restored. +* `.spec.to.user`: the accessing user of the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be restored. +* `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. +* `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster. 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 0000000000000..b6d440ffd5f1e --- /dev/null +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -0,0 +1,101 @@ +--- +title: Restore Data From S3-Compatible Storage +summary: Learn how to restore data from the S3-compatible storage. +category: how-to +--- + +# Restore Data From S3-Compatible Storage + +本文描述了将 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 集群。 + +This document describes how to restore the TiDB cluster data backed up by TiDB Operator in Kubernetes. For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. + +The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). + +This document shows a use case in which the backup data stored in the specified path on the S3-compatible storage is restored to the TiDB cluster. + +## 环境准备 + +## Prerequisites + +1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 资源，所需命令如下： + +1. Download [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml) and execute the following command to create the role-based access control (RBAC) resources in the `test2` namespace: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f backup-rbac.yaml -n test2 + ``` + +2. 创建 `restore-demo2-tidb-secret` secret，该 secret 存放用来访问 TiDB 集群的 root 账号和密钥： + +2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl create secret generic restore-demo2-tidb-secret --from-literal=user=root --from-literal=password= --namespace=test2 + ``` + +## Restoration process + +1. Create the restore custom resource (CR) and restore the backup data to the TiDB cluster: + + {{< copyable "shell-regular" >}} + + ```shell + kubectl apply -f restore.yaml + ``` + + The `restore.yaml` file has the following content: + + ```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. After creating the `Restore` CR, execute the following command to check the restoration status: + + {{< 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-的存储)。 + +In the above example, the backup data stored in the `spec.s3.path` path on the S3-compatible storage is restored to the `spec.to.host` TiDB cluster. For the configuration of the S3-compatible storage, refer to [backup-s3.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md#ad-hoc-backup-process). + +更多 `Restore` CR 字段的详细解释： + +More `Restore` CRs are as described follows: + +* `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. +* `.spec.to.host`: the accessing address of the TiDB cluster to be restored. +* `.spec.to.port`: the accessing port of the TiDB cluster to be restored. +* `.spec.to.user`: the accessing user of the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be restored. +* `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. +* `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster. diff --git a/tidb-in-kubernetes/reference/configuration/storage-class.md b/tidb-in-kubernetes/reference/configuration/storage-class.md index 1d435b40c03d5..9c1d00fe4188b 100644 --- a/tidb-in-kubernetes/reference/configuration/storage-class.md +++ b/tidb-in-kubernetes/reference/configuration/storage-class.md @@ -114,7 +114,7 @@ If the components such as monitoring, TiDB Binlog, and `tidb-backup` use local d >**Note:** > - > The number of directories you create depends on the planned number of TiDB clusters, the number of Pumps in each cluster, and your backup method. For each directory, a corresponding PV will be created. Each Pump uses one PV and each Drainer uses one PV. Each [Ad-hoc full backup](/tidb-in-kubernetes/maintain/backup-and-restore.md#ad-hoc-full-backup) task uses one PV, and all [scheduled full backup](/tidb-in-kubernetes/maintain/backup-and-restore.md#scheduled-full-backup) tasks share one PV. + > The number of directories you create depends on the planned number of TiDB clusters, the number of Pumps in each cluster, and your backup method. For each directory, a corresponding PV will be created. Each Pump uses one PV and each Drainer uses one PV. Each [Ad-hoc full backup](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md#ad-hoc-full-backup) task uses one PV, and all [scheduled full backup](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md#scheduled-full-backup) tasks share one PV. - For a disk storing data in PD, follow the [steps](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/operations.md#sharing-a-disk-filesystem-by-multiple-filesystem-pvs) to mount the disk. First, create multiple directories in disk, and bind mount them into `/mnt/sharedssd` directory. Then, create `shared-ssd-storage` `StorageClass` for them to use. diff --git a/tidb-in-kubernetes/tidb-operator-overview.md b/tidb-in-kubernetes/tidb-operator-overview.md index ff9dd643b6720..12157b0a62fc5 100644 --- a/tidb-in-kubernetes/tidb-operator-overview.md +++ b/tidb-in-kubernetes/tidb-operator-overview.md @@ -65,7 +65,7 @@ After the deployment is complete, see the following documents to use, operate, a + [Scale TiDB Cluster](/tidb-in-kubernetes/scale-in-kubernetes.md) + [Upgrade TiDB Cluster](/tidb-in-kubernetes/upgrade/tidb-cluster.md#upgrade-the-version-of-tidb-cluster) + [Change the Configuration of TiDB Cluster](/tidb-in-kubernetes/upgrade/tidb-cluster.md#change-the-configuration-of-tidb-cluster) -+ [Backup and Restore](/tidb-in-kubernetes/maintain/backup-and-restore.md) ++ [Backup and Restore](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md) + [Automatic Failover](/tidb-in-kubernetes/maintain/auto-failover.md) + [Monitor a TiDB Cluster in Kubernetes](/tidb-in-kubernetes/monitor/tidb-in-kubernetes.md) + [Collect TiDB Logs in Kubernetes](/tidb-in-kubernetes/maintain/log-collecting.md) From 41d281f8fecffdc0edc8714b463f03e1b3ff2535 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 4 Mar 2020 20:47:28 +0800 Subject: [PATCH 2/4] fix CI failure --- .../maintain/backup-and-restore/backup-gcs.md | 6 +++--- .../maintain/backup-and-restore/backup-s3.md | 4 ++-- .../maintain/backup-and-restore/restore-gcs.md | 4 ++-- .../maintain/backup-and-restore/restore-s3.md | 18 +----------------- 4 files changed, 8 insertions(+), 24 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 1cdcbce5104fc..02f205313c818 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -14,7 +14,7 @@ The backup method described in this document is implemented based on CustomResou Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. -To better explain how to perform the backup operation to GCS, this document shows a use case which backs up data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace. +To better explain how to perform the backup operation to GCS, this document shows an example in which the data of the `demo1` TiDB cluster is backed up to the `test1` Kubernetes namespace. ### Prerequisites for ad-hoc backup @@ -78,7 +78,7 @@ spec: storageSize: 10Gi ``` -The above case exports and backs up all data of the TiDB cluster to GCS. You can ignore the `location`, `objectAcl`, `bucketAcl`, and `storageClass` items in the GCS configuration. +In the above two examples, all data of the TiDB cluster is exported and backed up to GCS. You can ignore the `location`, `objectAcl`, `bucketAcl`, and `storageClass` items in the GCS configuration. `projectId` in the configuration is the unique identifier of the user project on GCP. To learn how to get this identifier, refer to the [GCP documentation](https://cloud.google.com/resource-manager/docs/creating-managing-projects). @@ -196,7 +196,7 @@ Execute the following command to check all the backup items: kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-gcs -n test1 ``` -From the above case, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the GCS storage, which is the same with the configurations for the ad-hoc full backup to GCS (refer to [GCS backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: +From the above example, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the GCS storage, which is the same with the configurations for the ad-hoc full backup to GCS (refer to [GCS backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: + `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. + `.spec.maxReservedTime`: a backup retention policy based on the time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the format of the time, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting prevails. 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 2b5010b2012e6..c1a30cfbc1630 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -14,7 +14,7 @@ The backup method described in this document is implemented based on CustomResou Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. -For the current S3-compatible storages, Ceph and Amazon S3 work normally as tested. Therefore, this document shows use cases which back up data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace to Ceph and Amazon S3 respectively. +For the current S3-compatible storages, Ceph and Amazon S3 work normally as tested. Therefore, this document shows use examples in which the data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace is backed up to Ceph and Amazon S3 respectively. ### Prerequisites for ad-hoc backup @@ -109,7 +109,7 @@ For the current S3-compatible storages, Ceph and Amazon S3 work normally as test storageSize: 10Gi ``` -The above two cases export and back up all data of the TiDB cluster to Amazon S3 and Ceph respectively. You can ignore the `region`, `acl`, `endpoint`, and `storageClass` configuration items in the Amazon S3 configuration. You can also leave empty the configuration item fields if you do not need to configure these items as shown in the above Ceph configuration. +In the above two examples, all data of the TiDB cluster is exported and backed up to Amazon S3 and Ceph respectively. You can ignore the `region`, `acl`, `endpoint`, and `storageClass` configuration items in the Amazon S3 configuration. You can also leave empty the configuration item fields if you do not need to configure these items as shown in the above Ceph configuration. Amazon S3 supports the following access control list (ACL) polices: 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 889c528b835bc..9adbfbf88d5d2 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -10,7 +10,7 @@ This document describes how to restore the TiDB cluster data backed up by TiDB O The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). -This document shows a use case in which the backup data stored in the specified path on [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) is restored to the TiDB cluster. +This document shows an example in which the backup data stored in the specified path on [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/) is restored to the TiDB cluster. ## Prerequisites @@ -71,7 +71,7 @@ This document shows a use case in which the backup data stored in the specified kubectl get rt -n test2 -owide ``` -The above case restores the backup data stored in the specified `spec.gcs.path` path on GCS to the `spec.to.host` TiDB cluster. For the configuration of GCS, refer to [backup-gcs.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md#ad-hoc-backup-process). +In the above example, the backup data stored in the specified `spec.gcs.path` path on GCS is restored to the `spec.to.host` TiDB cluster. For the configuration of GCS, refer to [backup-gcs.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md#ad-hoc-backup-process). More `Restore` CRs are as described follows: 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 b6d440ffd5f1e..3c3821fc72667 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -6,24 +6,14 @@ category: how-to # Restore Data From S3-Compatible Storage -本文描述了将 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 集群。 - This document describes how to restore the TiDB cluster data backed up by TiDB Operator in Kubernetes. For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). -This document shows a use case in which the backup data stored in the specified path on the S3-compatible storage is restored to the TiDB cluster. - -## 环境准备 +This document shows an example in which the backup data stored in the specified path on the S3-compatible storage is restored to the TiDB cluster. ## Prerequisites -1. 下载文件 [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml)，并在 `test2` 这个 namespace 中创建恢复备份所需的 RBAC 资源，所需命令如下： - 1. Download [`backup-rbac.yaml`](https://github.com/pingcap/tidb-operator/blob/master/manifests/backup/backup-rbac.yaml) and execute the following command to create the role-based access control (RBAC) resources in the `test2` namespace: {{< copyable "shell-regular" >}} @@ -32,8 +22,6 @@ This document shows a use case in which the backup data stored in the specified kubectl apply -f backup-rbac.yaml -n test2 ``` -2. 创建 `restore-demo2-tidb-secret` secret，该 secret 存放用来访问 TiDB 集群的 root 账号和密钥： - 2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: {{< copyable "shell-regular" >}} @@ -84,12 +72,8 @@ This document shows a use case in which the backup data stored in the specified 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-的存储)。 - In the above example, the backup data stored in the `spec.s3.path` path on the S3-compatible storage is restored to the `spec.to.host` TiDB cluster. For the configuration of the S3-compatible storage, refer to [backup-s3.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md#ad-hoc-backup-process). -更多 `Restore` CR 字段的详细解释： - More `Restore` CRs are as described follows: * `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. From 5adbe49e4ee1429866cf907ac295f19dc9603a9c Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Mon, 9 Mar 2020 15:08:21 +0800 Subject: [PATCH 3/4] tidb-in-kubernetes: refine language --- .../maintain/backup-and-restore/backup-gcs.md | 32 +++++++++---------- .../maintain/backup-and-restore/backup-s3.md | 32 +++++++++---------- .../maintain/backup-and-restore/charts.md | 2 +- .../backup-and-restore/restore-gcs.md | 12 +++---- .../maintain/backup-and-restore/restore-s3.md | 10 +++--- 5 files changed, 43 insertions(+), 45 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 02f205313c818..3d3bbd3628960 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -6,15 +6,15 @@ category: how-to # Back up TiDB Cluster Data to GCS -This document describes how to back up data of the TiDB cluster in Kubernetes to [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/). "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the remote GCS. +This document describes how to back up the data of the TiDB cluster in Kubernetes to [Google Cloud Storage (GCS)](https://cloud.google.com/storage/docs/). "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the remote GCS. The backup method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the backup method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). ## Ad-hoc full backup to GCS -Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. +Ad-hoc full backup describes a backup operation by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. -To better explain how to perform the backup operation to GCS, this document shows an example in which the data of the `demo1` TiDB cluster is backed up to the `test1` Kubernetes namespace. +To better explain how to perform the backup operation, this document shows an example in which the data of the `demo1` TiDB cluster is backed up to the `test1` Kubernetes namespace. ### Prerequisites for ad-hoc backup @@ -34,7 +34,7 @@ To better explain how to perform the backup operation to GCS, this document show kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1 ``` -3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: +3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password needed to access the TiDB cluster: {{< copyable "shell-regular" >}} @@ -78,7 +78,7 @@ spec: storageSize: 10Gi ``` -In the above two examples, all data of the TiDB cluster is exported and backed up to GCS. You can ignore the `location`, `objectAcl`, `bucketAcl`, and `storageClass` items in the GCS configuration. +In the above example, all data of the TiDB cluster is exported and backed up to GCS. You can ignore the `location`, `objectAcl`, `bucketAcl`, and `storageClass` items in the GCS configuration. `projectId` in the configuration is the unique identifier of the user project on GCP. To learn how to get this identifier, refer to the [GCP documentation](https://cloud.google.com/resource-manager/docs/creating-managing-projects). @@ -92,7 +92,7 @@ GCS supports the following `storageClass` types: If `storageClass` is not configured, `COLDLINE` is used by default. For the detailed description of these storage types, refer to [GCS documentation](https://cloud.google.com/storage/docs/storage-classes). -GCS supports the following object access control list (ACL) polices: +GCS supports the following object access-control list (ACL) polices: * `authenticatedRead` * `bucketOwnerFullControl` @@ -113,7 +113,7 @@ GCS supports the following bucket ACL policies: If the bucket ACL policy is not configured, the `private` policy is used by default. For the detailed description of these access control policies, refer to [GCS documentation](https://cloud.google.com/storage/docs/access-control/lists). -After creating the `Backup` CR, use the following command to check the backup status: +After creating the `Backup` CR, execute the following command to check the backup status: {{< copyable "shell-regular" >}} @@ -124,10 +124,10 @@ After creating the `Backup` CR, use the following command to check the backup st More `Backup` CRs are as described follows: * `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. -* `.spec.from.host`: the accessing address of the TiDB cluster to be backed up. -* `.spec.from.port`: the accessing port of the TiDB cluster to be backed up. +* `.spec.from.host`: the address of the TiDB cluster to be backed up. +* `.spec.from.port`: the port of the TiDB cluster to be backed up. * `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. -* `.spec.from.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be backed up. * `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. @@ -137,9 +137,9 @@ You can set a backup policy to perform scheduled backups of the TiDB cluster, an ### Prerequisites for scheduled backup -See the [Prerequisites for the ad-hoc backup](#prerequisites-for-ad-hoc-backup). +The prerequisites for the scheduled backup is the same with the [prerequisites for ad-hoc backup](#prerequisites-for-ad-hoc-backup). -### scheduled backup process +### Scheduled backup process Create the `BackupSchedule` CR to enable the scheduled full backup to GCS: @@ -196,9 +196,9 @@ Execute the following command to check all the backup items: kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-gcs -n test1 ``` -From the above example, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the GCS storage, which is the same with the configurations for the ad-hoc full backup to GCS (refer to [GCS backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: +From the above example, you can see that the `backupSchedule` configuration consists of two part. One is the unique configuration of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configuration related to the GCS storage, which is the same with the configuration of the ad-hoc full backup to GCS (refer to [GCS backup process](#ad-hoc-backup-process) for details). The following are the unique configuration items of `backupSchedule`: -+ `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. -+ `.spec.maxReservedTime`: a backup retention policy based on the time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the format of the time, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting prevails. -+ `.spec.schedule`: the time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. ++ `.spec.maxBackups`: A backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. ++ `.spec.maxReservedTime`: A backup retention policy based on time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the time format, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting takes effect. ++ `.spec.schedule`: The time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. + `.spec.pause`: `false` by default. If this parameter is set to `true`, the scheduled scheduling is paused. In this situation, the backup operation will not be performed even if the scheduling time is reached. During this pause, the backup [Garbage Collection](/reference/garbage-collection/overview.md) (GC) runs normally. If you change `true` to `false`, the full backup process is restarted. 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 c1a30cfbc1630..684f735aa0a2f 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -6,7 +6,7 @@ category: how-to # Back up TiDB Cluster Data to S3-Compatible Storage -This document describes how to back up data of the TiDB cluster in Kubernetes to the S3-compatible storage. "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the S3-compatible storage. +This document describes how to back up the data of the TiDB cluster in Kubernetes to the S3-compatible storage. "Backup" in this document refers to full backup (ad-hoc full backup and scheduled full backup). For the underlying implementation, [`mydumper`](/reference/tools/mydumper.md) is used to get the logic backup of the TiDB cluster, and then this backup data is sent to the S3-compatible storage. The backup method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the backup method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). @@ -14,7 +14,7 @@ The backup method described in this document is implemented based on CustomResou Ad-hoc full backup describes the backup by creating a `Backup` custom resource (CR) object. TiDB Operator performs the specific backup operation based on this `Backup` object. If an error occurs during the backup process, TiDB Operator does not retry and you need to handle this error manually. -For the current S3-compatible storages, Ceph and Amazon S3 work normally as tested. Therefore, this document shows use examples in which the data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace is backed up to Ceph and Amazon S3 respectively. +For the current S3-compatible storage types, Ceph and Amazon S3 work normally as tested. Therefore, this document shows examples in which the data of the `demo1` TiDB cluster in the `test1` Kubernetes namespace is backed up to Ceph and Amazon S3 respectively. ### Prerequisites for ad-hoc backup @@ -26,7 +26,7 @@ For the current S3-compatible storages, Ceph and Amazon S3 work normally as test kubectl apply -f backup-rbac.yaml -n test1 ``` -2. Create the `s3-secret` secret which stores the credential used to access the S3-compatible storage. +2. Create the `s3-secret` secret which stores the credential used to access the S3-compatible storage: {{< copyable "shell-regular" >}} @@ -34,7 +34,7 @@ For the current S3-compatible storages, Ceph and Amazon S3 work normally as test kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1 ``` -3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: +3. Create the `backup-demo1-tidb-secret` secret which stores the root account and password needed to access the TiDB cluster: {{< copyable "shell-regular" >}} @@ -109,9 +109,9 @@ For the current S3-compatible storages, Ceph and Amazon S3 work normally as test storageSize: 10Gi ``` -In the above two examples, all data of the TiDB cluster is exported and backed up to Amazon S3 and Ceph respectively. You can ignore the `region`, `acl`, `endpoint`, and `storageClass` configuration items in the Amazon S3 configuration. You can also leave empty the configuration item fields if you do not need to configure these items as shown in the above Ceph configuration. +In the above two examples, all data of the TiDB cluster is exported and backed up to Amazon S3 and Ceph respectively. You can ignore the `region`, `acl`, `endpoint`, and `storageClass` configuration items in the Amazon S3 configuration. S3-compatible storage types other than Amazon S3 can also use configuration similar to that of Amazon S3. You can also leave the configuration item fields empty if you do not need to configure these items as shown in the above Ceph configuration. -Amazon S3 supports the following access control list (ACL) polices: +Amazon S3 supports the following access-control list (ACL) polices: * `private` * `public-read` @@ -144,10 +144,10 @@ After creating the `Backup` CR, use the following command to check the backup st More `Backup` CRs are as described follows: * `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. -* `.spec.from.host`: the accessing address of the TiDB cluster to be backed up. -* `.spec.from.port`: the accessing port of the TiDB cluster to be backed up. +* `.spec.from.host`: the address of the TiDB cluster to be backed up. +* `.spec.from.port`: the port of the TiDB cluster to be backed up. * `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. -* `.spec.from.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be backed up. * `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. @@ -168,9 +168,7 @@ You can set a backup policy to perform scheduled backups of the TiDB cluster, an ### Prerequisites for scheduled backup -同 [Ad-hoc 全量备份环境准备](#ad-hoc-全量备份环境准备)。 - -See [Prerequisites for ad-hoc backup](#prerequisites-for-ad-hoc-backup) +The prerequisites for the scheduled backup is the same with the [prerequisites for ad-hoc backup](#prerequisites-for-ad-hoc-backup). ### Scheduled backup process @@ -257,7 +255,7 @@ After creating the scheduled full backup, use the following command to check the kubectl get bks -n test1 -owide ``` -Execute the followinsg command to check all the backup items: +Execute the following command to check all the backup items: {{< copyable "shell-regular" >}} @@ -265,9 +263,9 @@ Execute the followinsg command to check all the backup items: kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-s3 -n test1 ``` -From the above example, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configurations related to the S3-compatible storage, which is the same with the configurations for the ad-hoc full backup to the S3-compatible storage (refer to [Ad-hoc backup process](#ad-hoc-backup-process) for details). The following are the unique configurations of `backupSchedule`: +From the above two examples, you can see that the `backupSchedule` configuration consists of two part. One is the unique configurations of `backupSchedule` and the other is `backupTemplate`. `backupTemple` specifies the configuration related to the S3-compatible storage, which is the same with the configuration of the ad-hoc full backup to the S3-compatible storage (refer to [Ad-hoc backup process](#ad-hoc-backup-process) for details). The following are the unique configuration items of `backupSchedule`: -+ `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. -+ `.spec.maxReservedTime`: a backup retention policy based on the time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the format of the time, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting prevails. -+ `.spec.schedule`: the time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. ++ `.spec.maxBackups`: A backup retention policy, which determines the maximum number of backup items to be retained. When this value is exceeded, the outdated backup items will be deleted. If you set this configuration item to `0`, all backup items are retained. ++ `.spec.maxReservedTime`: A backup retention policy based on time. For example, if you set the value of this configuration to `24h`, backup items only of recent 24 hours are retained. All backup items out of this time are deleted. For the time format, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set the maximum number of backup items and the longest retention time of backup items at the same time, the latter setting takes effect. ++ `.spec.schedule`: The time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details. + `.spec.pause`: `false` by default. If this parameter is set to `true`, the scheduled scheduling is paused. In this situation, the backup operation will not be performed even if the scheduling time is reached. During this pause, the backup [Garbage Collection](/reference/garbage-collection/overview.md) (GC) runs normally. If you change `true` to `false`, the full backup process is restarted. diff --git a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md index 1507627b7cc9c..51f54a771fed7 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/charts.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/charts.md @@ -9,7 +9,7 @@ aliases: ['/docs/dev/tidb-in-kubernetes/maintain/backup-and-store/'] This document describes how to back up and restore the data of a TiDB cluster in Kubernetes based on Helm Charts. -For TiDB Operator 1.1 or later versions, it is recommended that you back up and restore the data of TiDB in Kubernetes based on CustomResourceDefinition (CRD). Refer to the following documents for details: +For TiDB Operator 1.1 or later versions, it is recommended that you use the backup and restoration methods based on CustomResourceDefinition (CRD). Refer to the following documents for details: - [Back up TiDB Cluster Data to GCS](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md) - [Restore Data From 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 9adbfbf88d5d2..47d0de0da4daa 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -6,7 +6,7 @@ category: how-to # Restore Data From GCS -This document describes how to restore the TiDB cluster data backed up by TiDB Operator in Kubernetes For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. +This document describes how to restore the TiDB cluster data backed up using TiDB Operator in Kubernetes. For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). @@ -20,9 +20,9 @@ This document shows an example in which the backup data stored in the specified ```shell kubectl apply -f backup-rbac.yaml -n test2 - ```： + ``` -2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: +2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password needed to access the TiDB cluster: {{< copyable "shell-regular" >}} @@ -76,9 +76,9 @@ In the above example, the backup data stored in the specified `spec.gcs.path` pa More `Restore` CRs are as described follows: * `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. -* `.spec.to.host`: the accessing address of the TiDB cluster to be restored. -* `.spec.to.port`: the accessing port of the TiDB cluster to be restored. +* `.spec.to.host`: the address of the TiDB cluster to be restored. +* `.spec.to.port`: the port of the TiDB cluster to be restored. * `.spec.to.user`: the accessing user of the TiDB cluster to be restored. -* `.spec.to.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be restored. * `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster. 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 3c3821fc72667..76ab7e74abbfa 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -6,7 +6,7 @@ category: how-to # Restore Data From S3-Compatible Storage -This document describes how to restore the TiDB cluster data backed up by TiDB Operator in Kubernetes. For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. +This document describes how to restore the TiDB cluster data backed up using TiDB Operator in Kubernetes. For the underlying implementation, [`loader`](/reference/tools/loader.md) is used to perform the restoration. The restoration method described in this document is implemented based on CustomResourceDefinition (CRD) in TiDB Operator v1.1 or later versions. For the restoration method implemented based on Helm Charts, refer to [Back up and Restore TiDB Cluster Data Based on Helm Charts](/tidb-in-kubernetes/maintain/backup-and-restore/charts.md). @@ -22,7 +22,7 @@ This document shows an example in which the backup data stored in the specified kubectl apply -f backup-rbac.yaml -n test2 ``` -2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password used to access the TiDB cluster: +2. Create the `restore-demo2-tidb-secret` secret which stores the root account and password needed to access the TiDB cluster: {{< copyable "shell-regular" >}} @@ -77,9 +77,9 @@ In the above example, the backup data stored in the `spec.s3.path` path on the S More `Restore` CRs are as described follows: * `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. -* `.spec.to.host`: the accessing address of the TiDB cluster to be restored. -* `.spec.to.port`: the accessing port of the TiDB cluster to be restored. +* `.spec.to.host`: the address of the TiDB cluster to be restored. +* `.spec.to.port`: the port of the TiDB cluster to be restored. * `.spec.to.user`: the accessing user of the TiDB cluster to be restored. -* `.spec.to.tidbSecretName`: the secrete of the credential required by the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be restored. * `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster. From 79d3603eef2f823c39d9d6f165b9766ab8c63e53 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Mon, 16 Mar 2020 11:56:51 +0800 Subject: [PATCH 4/4] address comments from tennix --- .../maintain/backup-and-restore/backup-gcs.md | 6 +++--- tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md | 4 ++-- .../maintain/backup-and-restore/restore-gcs.md | 4 ++-- .../maintain/backup-and-restore/restore-s3.md | 4 ++-- 4 files changed, 9 insertions(+), 9 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 3d3bbd3628960..b39c216593d5c 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md @@ -44,7 +44,7 @@ To better explain how to perform the backup operation, this document shows an ex ### Ad-hoc backup process -Create the `Backup` CR and back up data to GSC: +Create the `Backup` CR and back up data to GCS: {{< copyable "shell-regular" >}} @@ -121,13 +121,13 @@ After creating the `Backup` CR, execute the following command to check the backu kubectl get bk -n test1 -owide ``` -More `Backup` CRs are as described follows: +More `Backup` CR configurations are as described follows: * `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. * `.spec.from.host`: the address of the TiDB cluster to be backed up. * `.spec.from.port`: the port of the TiDB cluster to be backed up. * `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. -* `.spec.from.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secret of the credential needed by the TiDB cluster to be backed up. * `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. 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 684f735aa0a2f..92dbcc9e550ce 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md @@ -141,13 +141,13 @@ After creating the `Backup` CR, use the following command to check the backup st kubectl get bk -n test1 -owide ``` -More `Backup` CRs are as described follows: +More `Backup` CR configurations are as described follows: * `.spec.metadata.namespace`: the namespace where the `Backup` CR is located. * `.spec.from.host`: the address of the TiDB cluster to be backed up. * `.spec.from.port`: the port of the TiDB cluster to be backed up. * `.spec.from.user`: the accessing user of the TiDB cluster to be backed up. -* `.spec.from.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be backed up. +* `.spec.from.tidbSecretName`: the secret of the credential needed by the TiDB cluster to be backed up. * `.spec.storageClassName`: the persistent volume (PV) type specified for the backup operation. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the backup operation. This value must be greater than size of the TiDB cluster to be backed up. 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 47d0de0da4daa..2205dd381defc 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-gcs.md @@ -73,12 +73,12 @@ This document shows an example in which the backup data stored in the specified In the above example, the backup data stored in the specified `spec.gcs.path` path on GCS is restored to the `spec.to.host` TiDB cluster. For the configuration of GCS, refer to [backup-gcs.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-gcs.md#ad-hoc-backup-process). -More `Restore` CRs are as described follows: +More `Restore` CR configurations are as described follows: * `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. * `.spec.to.host`: the address of the TiDB cluster to be restored. * `.spec.to.port`: the port of the TiDB cluster to be restored. * `.spec.to.user`: the accessing user of the TiDB cluster to be restored. -* `.spec.to.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secret of the credential needed by the TiDB cluster to be restored. * `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster. 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 76ab7e74abbfa..b0d2b2bc46970 100644 --- a/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md +++ b/tidb-in-kubernetes/maintain/backup-and-restore/restore-s3.md @@ -74,12 +74,12 @@ This document shows an example in which the backup data stored in the specified In the above example, the backup data stored in the `spec.s3.path` path on the S3-compatible storage is restored to the `spec.to.host` TiDB cluster. For the configuration of the S3-compatible storage, refer to [backup-s3.yaml](/tidb-in-kubernetes/maintain/backup-and-restore/backup-s3.md#ad-hoc-backup-process). -More `Restore` CRs are as described follows: +More `Restore` CR configurations are as described follows: * `.spec.metadata.namespace`: the namespace where the `Restore` CR is located. * `.spec.to.host`: the address of the TiDB cluster to be restored. * `.spec.to.port`: the port of the TiDB cluster to be restored. * `.spec.to.user`: the accessing user of the TiDB cluster to be restored. -* `.spec.to.tidbSecretName`: the secrete of the credential needed by the TiDB cluster to be restored. +* `.spec.to.tidbSecretName`: the secret of the credential needed by the TiDB cluster to be restored. * `.spec.storageClassName`: the persistent volume (PV) type specified for the restoration. If this item is not specified, the value of the `default-backup-storage-class-name` parameter (`standard` by default, specified when TiDB Operator is started) is used by default. * `.spec.storageSize`: the PV size specified for the restoration. This value must be greater than size of the backed up TiDB cluster.