使用 Mydumper 备份 TiDB 集群数据到 GCS
- Ad-hoc 全量备份
  - Ad-hoc 全量备份环境准备
  - 备份数据到 GCS
- 定时全量备份
  - 定时全量备份环境准备
  - 定时全量备份数据到 GCS

使用 Mydumper 备份 TiDB 集群数据到 GCS

本文档详细描述了如何将 Kubernetes 上 TiDB 集群的数据备份到 Google Cloud Storage (GCS) 上。本文档中的“备份”，均是指全量备份（Ad-hoc 全量备份和定时全量备份），底层通过使用 mydumper 获取集群的逻辑备份，然后再将备份数据上传到远端 GCS。

本文使用的备份方式基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。基于 Helm Charts 的备份和恢复方式可参考基于 Helm Charts 实现的 TiDB 集群备份与恢复。

Ad-hoc 全量备份

Ad-hoc 全量备份通过创建一个自定义的 Backup custom resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 Backup 对象来完成具体的备份过程。如果备份过程中出现错误，程序不会自动重试，此时需要手动处理。

为了更好地描述备份的使用方式，本文档提供如下备份示例。示例假设对部署在 Kubernetes test1 这个 namespace 中的 TiDB 集群 demo1 进行数据备份，下面是具体操作过程。

Ad-hoc 全量备份环境准备

下载文件 backup-rbac.yaml，并执行以下命令在 test1 这个 namespace 中创建备份需要的 RBAC 相关资源：
```
 kubectl apply -f backup-rbac.yaml -n test1
```
创建 gcs-secret secret。该 secret 存放用于访问 GCS 的凭证。google-credentials.json 文件存放用户从 GCP console 上下载的 service account key。具体操作参考 GCP 官方文档。
```
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
```

创建 backup-demo1-tidb-secret secret。该 secret 存放用于访问 TiDB 集群的 root 账号和密钥。

 kubectl create secret generic backup-demo1-tidb-secret --from-literal=password=${password} --namespace=test1

备份数据到 GCS

创建 Backup CR，并将数据备份到 GCS：

kubectl apply -f backup-gcs.yaml

backup-gcs.yaml 文件内容如下：

---
apiVersion: pingcap.com/v1alpha1
kind: Backup
metadata:
  name: demo1-backup-gcs
  namespace: test1
spec:
  from:
    host: ${tidb_host}
    port: ${tidb_port}
    user: ${tidb_user}
    secretName: backup-demo1-tidb-secret
  gcs:
    secretName: gcs-secret
    projectId: ${project_id}
    bucket: ${bucket}
    # prefix: ${prefix}
    # location: us-east1
    # storageClass: STANDARD_IA
    # objectAcl: private
    # bucketAcl: private
# mydumper:
#  options:
#  - --tidb-force-priority=LOW_PRIORITY
#  - --long-query-guard=3600
#  - --threads=16
#  - --rows=10000
#  - --skip-tz-utc
#  - --verbose=3
#  tableRegex: "^test"
  storageClassName: local-storage
  storageSize: 10Gi

以上示例将 TiDB 集群的数据全量导出备份到 GCS。GCS 配置中的 location、objectAcl、bucketAcl、storageClass 项均可以省略。

配置中的 projectId 代表 GCP 上用户项目的唯一标识。具体获取该标识的方法可参考 GCP 官方文档。

GCS 支持以下几种 storageClass 类型：

MULTI_REGIONAL
REGIONAL
NEARLINE
COLDLINE
DURABLE_REDUCED_AVAILABILITY

如果不设置 storageClass，则默认使用 COLDLINE。这几种存储类型的详细介绍可参考 GCS 官方文档。

GCS 支持以下几种 object access-control list (ACL) 策略：

authenticatedRead
bucketOwnerFullControl
bucketOwnerRead
private
projectPrivate
publicRead

如果不设置 object ACL 策略，则默认使用 private 策略。这几种访问控制策略的详细介绍可参考 GCS 官方文档。

GCS 支持以下几种 bucket ACL 策略：

authenticatedRead
private
projectPrivate
publicRead
publicReadWrite

如果不设置 bucket ACL 策略，则默认策略为 private。这几种访问控制策略的详细介绍可参考 GCS 官方文档。

创建好 Backup CR 后，可通过以下命令查看备份状态：

 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.gcs.bucket：存储数据的 bucket 名字。
.spec.gcs.prefix：这个字段可以省略，如果设置了这个字段，则会使用这个字段来拼接在远端存储的存储路径 s3://${.spec.gcs.bucket}/${.spec.gcs.prefix}/backupName。
.spec.mydumper：Mydumper 相关的配置，主要有两个字段：一个是 options 字段，里面可以指定 mydumper 需要的一些参数；一个是 tableRegex 字段，可以指定让 Mydumper 备份符合这个正则表达式的表。默认情况下 Mydumper 这个字段可以不用配置。当不指定 Mydumper 的配置时，options 和 tableRegex 字段的默认值如下：
```
  options:
  --tidb-force-priority=LOW_PRIORITY
  --long-query-guard=3600
  --threads=16
  --rows=10000
  --skip-tz-utc
  --verbose=3
 tableRegex: "^(?!(mysql|test|INFORMATION_SCHEMA|PERFORMANCE_SCHEMA|METRICS_SCHEMA|INSPECTION_SCHEMA))"
```
.spec.storageClassName：备份时指定所需的 persistent volume (PV) 类型。如果不指定该项，则默认使用 TiDB Operator 启动参数中 default-backup-storage-class-name 指定的值，该值默认为 standard。
.spec.storageSize：备份时指定所需的 PV 大小。该值应大于备份 TiDB 集群数据的大小。

定时全量备份

用户通过设置备份策略来对 TiDB 集群进行定时备份，同时设置备份的保留策略以避免产生过多的备份。定时全量备份通过自定义的 BackupSchedule CR 对象来描述。每到备份时间点会触发一次全量备份，定时全量备份底层通过 Ad-hoc 全量备份来实现。下面是创建定时全量备份的具体步骤：

定时全量备份环境准备

同 Ad-hoc 全量备份环境准备。

定时全量备份数据到 GCS

创建 BackupSchedule CR 开启 TiDB 集群的定时全量备份，将数据备份到 GCS：

kubectl apply -f backup-schedule-gcs.yaml

backup-schedule-gcs.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: ${tidb_host}
      port: ${tidb_port}
      user: ${tidb_user}
      secretName: backup-demo1-tidb-secret
    gcs:
      secretName: gcs-secret
      projectId: ${project_id}
      bucket: ${bucket}
      # prefix: ${prefix}
      # location: us-east1
      # storageClass: STANDARD_IA
      # objectAcl: private
      # bucketAcl: private
  # mydumper:
  #  options:
  #  - --tidb-force-priority=LOW_PRIORITY
  #  - --long-query-guard=3600
  #  - --threads=16
  #  - --rows=10000
  #  - --skip-tz-utc
  #  - --verbose=3
  #  tableRegex: "^test"
    storageClassName: local-storage
    storageSize: 10Gi

定时全量备份创建完成后，可以通过以下命令查看定时全量备份的状态：

kubectl get bks -n test1 -owide

查看定时全量备份下面所有的备份条目：

 kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-gcs -n test1

从以上示例可知，backupSchedule 的配置由两部分组成。一部分是 backupSchedule 独有的配置，另一部分是 backupTemplate。backupTemplate 指定 GCS 存储相关的配置，该配置与 Ad-hoc 全量备份到 GCS 的配置完全一样，可参考备份数据到 GCS。下面介绍 backupSchedule 独有的配置项：

.spec.maxBackups：一种备份保留策略，决定定时备份最多可保留的备份个数。超过该数目，就会将过时的备份删除。如果将该项设置为 0，则表示保留所有备份。
.spec.maxReservedTime：一种备份保留策略，按时间保留备份。比如将该参数设置为 24h，表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考func ParseDuration。如果同时设置最大备份保留个数和最长备份保留时间，则以最长备份保留时间为准。
.spec.schedule：Cron 的时间调度格式。具体格式可参考 Cron。
.spec.pause：该值默认为 false。如果将该值设置为 true，表示暂停定时调度。此时即使到了调度时间点，也不会进行备份。在定时备份暂停期间，备份 Garbage Collection (GC) 仍然正常进行。将 true 改为 false 则重新开启定时全量备份。