使用 BR 工具恢复 S3 兼容存储上的备份数据

优质

小牛编辑

138浏览

2023-12-01

本文详细描述了如何将存储在 Amazon S3 存储的备份数据恢复到 AWS Kubernetes 环境中的 TiDB 集群，底层通过使用 BR 进行数据恢复。

本文使用的恢复方式基于 TiDB Operator 新版（v1.1 及以上）的 Custom Resource Definition (CRD) 实现。

以下示例将 Amazon S3 的存储（指定路径）上的备份数据恢复到 AWS Kubernetes 环境中的 TiDB 集群。

AWS 账号的三种权限授予方式

参考使用 BR 工具备份 AWS 上的 TiDB 集群

环境准备

通过 AccessKey 和 SecretKey 授权

下载文件 backup-rbac.yaml，并执行以下命令在 test2 这个 namespace 中创建备份需要的 RBAC 相关资源：
```
kubectl apply -f backup-rbac.yaml -n test2
```

创建 s3-secret secret。该 secret 存放用于访问 S3 兼容存储的凭证。

kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test2

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

kubectl create secret generic restore-demo2-tidb-secret --from-literal=password=${password} --namespace=test2

通过 IAM 绑定 Pod 授权

下载文件 backup-rbac.yaml，并执行以下命令在 test2 这个 namespace 中创建备份需要的 RBAC 相关资源：
```
kubectl apply -f backup-rbac.yaml -n test2
```

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

kubectl create secret generic restore-demo2-tidb-secret --from-literal=password=${password} --namespace=test2

创建 IAM 角色：
可以参考 AWS 官方文档来为账号创建一个 IAM 角色，并且通过 AWS 官方文档为 IAM 角色赋予需要的权限。由于 Restore 需要访问 AWS 的 S3 存储，所以这里给 IAM 赋予了 AmazonS3FullAccess 的权限。
绑定 IAM 到 TiKV Pod:
在使用 BR 备份的过程中，TiKV Pod 和 BR Pod 一样需要对 S3 存储进行读写操作，所以这里需要给 TiKV Pod 打上 annotation 来绑定 IAM 角色。
```
kubectl edit tc demo2 -n test2
```
找到 spec.tikv.annotations, 增加 annotation arn:aws:iam::123456789012:role/user, 然后退出编辑, 等到 TiKV Pod 重启后，查看 Pod 是否加上了这个 annotation。

注意：
arn:aws:iam::123456789012:role/user 为步骤 4 中创建的 IAM 角色。

通过 IAM 绑定 ServiceAccount 授权

下载文件 backup-rbac.yaml，并执行以下命令在 test2 这个 namespace 中创建备份需要的 RBAC 相关资源：
```
kubectl apply -f backup-rbac.yaml -n test2
```

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

kubectl create secret generic restore-demo2-tidb-secret --from-literal=password=${password} --namespace=test2

在集群上为服务帐户启用 IAM 角色：
可以参考 AWS 官方文档开启所在的 EKS 集群的 IAM 角色授权。
创建 IAM 角色:
可以参考 AWS 官方文档创建一个 IAM 角色，为角色赋予 AmazonS3FullAccess 的权限，并且编辑角色的 Trust relationships。

绑定 IAM 到 ServiceAccount 资源上：

kubectl annotate sa tidb-backup-manager -n eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test2

将 ServiceAccount 绑定到 TiKV Pod：
```
kubectl edit tc demo2 -n test2
```
将 spec.tikv.serviceAccount 修改为 tidb-backup-manager , 等到 TiKV Pod 重启后，查看 Pod 的 serviceAccountName 是否有变化。

注意：
arn:aws:iam::123456789012:role/user 为步骤 4 中创建的 IAM 角色。

数据库账户权限

mysql.tidb 表的 SELECT 和 UPDATE 权限：恢复前后，restore CR 需要一个拥有该权限的数据库账户，用于调整 GC 时间

将指定备份数据恢复到 TiDB 集群

创建 Restore CR，通过 accessKey 和 secretKey 授权的方式恢复集群：

kubectl apply -f resotre-aws-s3.yaml

restore-aws-s3.yaml 文件内容如下：

---
apiVersion: pingcap.com/v1alpha1
kind: Restore
metadata:
  name: demo2-restore-s3
  namespace: test2
spec:
  br:
    cluster: demo2
    clusterNamespace: test2
    # logLevel: info
    # statusAddr: ${status_addr}
    # concurrency: 4
    # rateLimit: 0
    # timeAgo: ${time}
    # checksum: true
    # sendCredToTikv: true
  to:
    host: ${tidb_host}
    port: ${tidb_port}
    user: ${tidb_user}
    secretName: restore-demo2-tidb-secret
  s3:
    provider: aws
    secretName: s3-secret
    region: us-west-1
    bucket: my-bucket
    prefix: my-folder

创建 Restore CR，通过 IAM 绑定 Pod 授权的方式备份集群：

kubectl apply -f restore-aws-s3.yaml

restore-aws-s3.yaml 文件内容如下：

---
apiVersion: pingcap.com/v1alpha1
kind: Restore
metadata:
  name: demo2-restore-s3
  namespace: test2
  annotations:
    iam.amazonaws.com/role: arn:aws:iam::123456789012:role/user
spec:
  br:
    cluster: demo2
    sendCredToTikv: false
    clusterNamespace: test2
    # logLevel: info
    # statusAddr: ${status_addr}
    # concurrency: 4
    # rateLimit: 0
    # timeAgo: ${time}
    # checksum: true
  to:
    host: ${tidb_host}
    port: ${tidb_port}
    user: ${tidb_user}
    secretName: restore-demo2-tidb-secret
  s3:
    provider: aws
    region: us-west-1
    bucket: my-bucket
    prefix: my-folder

创建 Restore CR，通过 IAM 绑定 ServiceAccount 授权的方式备份集群：

kubectl apply -f restore-aws-s3.yaml

restore-aws-s3.yaml 文件内容如下：

---
apiVersion: pingcap.com/v1alpha1
kind: Restore
metadata:
  name: demo2-restore-s3
  namespace: test2
spec:
  serviceAccount: tidb-backup-manager
  br:
    cluster: demo2
    sendCredToTikv: false
    clusterNamespace: test2
    # logLevel: info
    # statusAddr: ${status_addr}
    # concurrency: 4
    # rateLimit: 0
    # timeAgo: ${time}
    # checksum: true
  to:
    host: ${tidb_host}
    port: ${tidb_port}
    user: ${tidb_user}
    secretName: restore-demo2-tidb-secret
  s3:
    provider: aws
    region: us-west-1
    bucket: my-bucket
    prefix: my-folder

创建好 Restore CR 后，可通过以下命令查看恢复的状态：

kubectl get rt -n test2 -o wide

更多 Restore CR 字段的详细解释：

.spec.metadata.namespace：Restore CR 所在的 namespace。
.spec.to.host：待恢复 TiDB 集群的访问地址。
.spec.to.port：待恢复 TiDB 集群的访问端口。
.spec.to.user：待恢复 TiDB 集群的访问用户。
.spec.to.tidbSecretName：待恢复 TiDB 集群 .spec.to.user 用户的密码所对应的 secret。
.spec.to.tlsClientSecretName：指定恢复备份使用的存储证书的 Secret。
如果 TiDB 集群开启了 TLS，但是不想使用文档中创建的 ${cluster_name}-cluster-client-secret 恢复备份，可以通过这个参数为恢复备份指定一个 Secret，可以通过如下命令生成：
```
kubectl create secret generic ${secret_name} --namespace=${namespace} --from-file=tls.crt=${cert_path} --from-file=tls.key=${key_path} --from-file=ca.crt=${ca_path}
```
.spec.tableFilter：恢复时指定让 BR 恢复符合 table-filter 规则的表。默认情况下该字段可以不用配置。当不配置时，BR 会恢复备份文件中的所有数据库：
注意：
tableFilter 如果要写排除规则导出除 db.table 的所有表，"!db.table" 前必须先添加 *.* 规则来导出所有表，如下面例子所示：
```
tableFilter:
- "*.*"
- "!db.table"
```

以上示例中，.spec.br 中的一些参数项均可省略，如 logLevel、statusAddr、concurrency、rateLimit、checksum、timeAgo、sendCredToTikv。

.spec.br.cluster：代表需要备份的集群名字。
.spec.br.clusterNamespace：代表需要备份的集群所在的 namespace。
.spec.br.logLevel：代表日志的级别。默认为 info。
.spec.br.statusAddr：为 BR 进程监听一个进程状态的 HTTP 端口，方便用户调试。如果不填，则默认不监听。
.spec.br.concurrency：备份时每一个 TiKV 进程使用的线程数。备份时默认为 4，恢复时默认为 128。
.spec.br.rateLimit：是否对流量进行限制。单位为 MB/s，例如设置为 4 代表限速 4 MB/s，默认不限速。
.spec.br.checksum：是否在备份结束之后对文件进行验证。默认为 true。
.spec.br.timeAgo：备份 timeAgo 以前的数据，默认为空（备份当前数据），支持 "1.5h", "2h45m" 等数据。
.spec.br.sendCredToTikv：BR 进程是否将自己的 GCP 权限传输给 TiKV 进程。默认为 true。

故障诊断

在使用过程中如果遇到问题，可以参考故障诊断。