使用 BR 工具备份 TiDB 集群数据到兼容 S3 的存储
本文详细描述了如何将运行在 AWS Kubernetes 环境中的 TiDB 集群数据备份到 AWS 的存储上。本文档中的“备份”,均是指全量备份(Ad-hoc 全量备份和定时全量备份)。底层通过使用 BR 获取集群的逻辑备份,然后再将备份数据上传到 AWS 的存储上。
本文使用的备份方式基于 TiDB Operator v1.1 及以上版本的 Custom Resource Definition(CRD) 实现。
AWS 账号权限授予的三种方式
在 AWS 云环境中,不同的类型的 Kubernetes 集群提供了不同的权限授予方式。本文测试了以下三种权限授予方式:
通过传入 AWS 账号的 AccessKey 和 SecretKey 进行授权:
AWS 的客户端支持读取进程环境变量中的
AWS_ACCESS_KEY_ID
以及AWS_SECRET_ACCESS_KEY
来获取与之相关联的用户或者角色的权限。通过将 IAM 绑定 Pod 进行授权:
通过将用户的 IAM 角色与所运行的 Pod 资源进行绑定,使 Pod 中运行的进程获得角色所拥有的权限,这种授权方式是由
kube2iam
提供。注意:
- 使用该授权模式时,可以参考
kube2iam 文档
在 Kubernetes 集群中创建 kube2iam 环境, 并且部署 TiDB Operator 以及 TiDB 集群。 - 该模式不适用于
hostNetwork
网络模式,请确保参数spec.tikv.hostNetwork
的值为false
。
- 使用该授权模式时,可以参考
通过将 IAM 绑定 ServiceAccount 进行授权:
通过将用户的 IAM 角色与 Kubeneters 中的
serviceAccount
资源进行绑定, 从而使得使用该 ServiceAccount 账号的 Pod 都拥有该角色所拥有的权限,这种授权方式由EKS Pod Identity Webhook
服务提供。使用该授权模式时,可以参考 AWS 官方文档 创建 EKS 集群, 并且部署 TiDB Operator 以及 TiDB 集群。
Ad-hoc 全量备份
Ad-hoc 全量备份通过创建一个自定义的 Backup
Custom Resource (CR) 对象来描述一次备份。TiDB Operator 根据这个 Backup
对象来完成具体的备份过程。如果备份过程中出现错误,程序不会自动重试,此时需要手动处理。
目前 Ad-hoc 全量备份已经兼容以上三种授权模式,本文档提供如下备份示例。示例假设对部署在 Kubernetes test1
这个 namespace 中的 TiDB 集群 demo1
进行数据备份,下面是具体操作过程。
Ad-hoc 全量备份环境准备
通过 AccessKey 和 SecretKey 授权
下载文件 backup-rbac.yaml,并执行以下命令在
test1
这个 namespace 中创建备份需要的 RBAC 相关资源:kubectl apply -f backup-rbac.yaml -n test1
创建
s3-secret
secret。该 secret 存放用于访问 S3 兼容存储的凭证。kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
创建
backup-demo1-tidb-secret
secret。该 secret 存放用于访问 TiDB 集群的用户所对应的密码。kubectl create secret generic backup-demo1-tidb-secret --from-literal=password=${password} --namespace=test1
通过 IAM 绑定 Pod 授权
下载文件 backup-rbac.yaml,并执行以下命令在
test1
这个 namespace 中创建备份需要的 RBAC 相关资源:kubectl apply -f backup-rbac.yaml -n test1
创建
backup-demo1-tidb-secret
secret。该 secret 存放用于访问 TiDB 集群的用户所对应的密码:kubectl create secret generic backup-demo1-tidb-secret --from-literal=password=${password} --namespace=test1
创建 IAM 角色:
可以参考 AWS 官方文档来为账号创建一个 IAM 角色,并且通过 AWS 官方文档 为 IAM 角色赋予需要的权限。由于
Backup
需要访问 AWS 的 S3 存储,所以这里给 IAM 赋予了AmazonS3FullAccess
的权限。绑定 IAM 到 TiKV Pod:
在使用 BR 备份的过程中,TiKV Pod 和 BR Pod 一样需要对 S3 存储进行读写操作,所以这里需要给 TiKV Pod 打上 annotation 来绑定 IAM 角色。
kubectl edit tc demo1 -n test1
找到
spec.tikv.annotations
,增加 annotationiam.amazonaws.com/role: arn:aws:iam::123456789012:role/user
,然后退出编辑,等到 TiKV Pod 重启后,查看 Pod 是否加上了这个 annotation。
注意:
arn:aws:iam::123456789012:role/user
为步骤 4 中创建的 IAM 角色。
通过 IAM 绑定 ServiceAccount 授权
下载文件 backup-rbac.yaml,并执行以下命令在
test1
这个 namespace 中创建备份需要的 RBAC 相关资源:kubectl apply -f backup-rbac.yaml -n test2
创建
backup-demo1-tidb-secret
secret。该 secret 存放用于访问 TiDB 集群的 root 账号和密钥:kubectl create secret generic backup-demo1-tidb-secret --from-literal=password=${password} --namespace=test1
在集群上为服务帐户启用 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=test1
将 ServiceAccount 绑定到 TiKV Pod:
kubectl edit tc demo1 -n test1
将
spec.tikv.serviceAccount
修改为 tidb-backup-manager,等到 TiKV Pod 重启后,查看 Pod 的serviceAccountName
是否有变化。
注意:
arn:aws:iam::123456789012:role/user
为步骤 4 中创建的 IAM 角色。
使用 BR 备份数据到 Amazon S3 的存储
创建
Backup
CR,通过 accessKey 和 secretKey 授权的方式备份集群:kubectl apply -f backup-aws-s3.yaml
backup-aws-s3.yaml
文件内容如下:---
apiVersion: pingcap.com/v1alpha1
kind: Backup
metadata:
name: demo1-backup-s3
namespace: test1
spec:
backupType: full
br:
cluster: demo1
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
# sendCredToTikv: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
secretName: s3-secret
region: us-west-1
bucket: my-bucket
prefix: my-folder
创建
Backup
CR,通过 IAM 绑定 Pod 授权的方式备份集群:kubectl apply -f backup-aws-s3.yaml
backup-aws-s3.yaml
文件内容如下:---
apiVersion: pingcap.com/v1alpha1
kind: Backup
metadata:
name: demo1-backup-s3
namespace: test1
annotations:
iam.amazonaws.com/role: arn:aws:iam::123456789012:role/user
spec:
backupType: full
br:
cluster: demo1
sendCredToTikv: false
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
region: us-west-1
bucket: my-bucket
prefix: my-folder
创建
Backup
CR,通过 IAM 绑定 ServiceAccount 授权的方式备份集群:kubectl apply -f backup-aws-s3.yaml
backup-aws-s3.yaml
文件内容如下:---
apiVersion: pingcap.com/v1alpha1
kind: Backup
metadata:
name: demo1-backup-s3
namespace: test1
spec:
backupType: full
serviceAccount: tidb-backup-manager
br:
cluster: demo1
sendCredToTikv: false
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
region: us-west-1
bucket: my-bucket
prefix: my-folder
以上三个示例分别使用三种授权模式将数据导出到 Amazon S3 存储上。Amazon S3 的 acl
、endpoint
、storageClass
配置项均可以省略。
Amazon S3 支持以下几种 access-control list (ACL) 策略:
private
public-read
public-read-write
authenticated-read
bucket-owner-read
bucket-owner-full-control
如果不设置 ACL 策略,则默认使用 private
策略。这几种访问控制策略的详细介绍参考 AWS 官方文档。
Amazon S3 支持以下几种 storageClass
类型:
STANDARD
REDUCED_REDUNDANCY
STANDARD_IA
ONEZONE_IA
GLACIER
DEEP_ARCHIVE
如果不设置 storageClass
,则默认使用 STANDARD_IA
。这几种存储类型的详细介绍参考 AWS 官方文档。
创建好 Backup
CR 后,可通过如下命令查看备份状态:
kubectl get bk -n test1 -o wide
更多 Backup
CR 字段的详细解释:
.spec.metadata.namespace
:Backup
CR 所在的 namespace。.spec.from.host
:待备份 TiDB 集群的访问地址。.spec.from.port
:待备份 TiDB 集群的访问端口。.spec.from.user
:待备份 TiDB 集群的访问用户。.spec.from.tidbSecretName
:待备份 TiDB 集群.spec.from.user
用户的密码所对应的 secret。.spec.from.tlsClient.tlsSecret
:指定备份使用的存储证书的 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}
更多支持的兼容 S3 的 provider
如下:
alibaba
:Alibaba Cloud Object Storage System (OSS) formerly Aliyundigitalocean
:Digital Ocean Spacesdreamhost
:Dreamhost DreamObjectsibmcos
:IBM COS S3minio
:Minio Object Storagenetease
:Netease Object Storage (NOS)wasabi
:Wasabi Object Storageother
:Any other S3 compatible provider
定时全量备份
用户通过设置备份策略来对 TiDB 集群进行定时备份,同时设置备份的保留策略以避免产生过多的备份。定时全量备份通过自定义的 BackupSchedule
CR 对象来描述。每到备份时间点会触发一次全量备份,定时全量备份底层通过 Ad-hoc 全量备份来实现。下面是创建定时全量备份的具体步骤:
定时全量备份环境准备
使用 BR 定时备份数据到 Amazon S3 的存储
创建
BackupSchedule
CR,开启 TiDB 集群定时全量备份,通过 accessKey 和 secretKey 授权的方式备份集群:kubectl apply -f backup-scheduler-aws-s3.yaml
backup-scheduler-aws-s3.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:
backupType: full
br:
cluster: demo1
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
# sendCredToTikv: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
secretName: s3-secret
region: us-west-1
bucket: my-bucket
prefix: my-folder
创建
BackupSchedule
CR,开启 TiDB 集群定时全量备份,通过 IAM 绑定 Pod 授权的方式备份集群:kubectl apply -f backup-scheduler-aws-s3.yaml
backup-scheduler-aws-s3.yaml
文件内容如下:---
apiVersion: pingcap.com/v1alpha1
kind: BackupSchedule
metadata:
name: demo1-backup-schedule-s3
namespace: test1
annotations:
iam.amazonaws.com/role: arn:aws:iam::123456789012:role/user
spec:
#maxBackups: 5
#pause: true
maxReservedTime: "3h"
schedule: "*/2 * * * *"
backupTemplate:
backupType: full
br:
cluster: demo1
sendCredToTikv: false
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
region: us-west-1
bucket: my-bucket
prefix: my-folder
创建
BackupSchedule
CR,开启 TiDB 集群定时全量备份, 通过 IAM 绑定 ServiceAccount 授权的方式备份集群:kubectl apply -f backup-scheduler-aws-s3.yaml
backup-scheduler-aws-s3.yaml
文件内容如下:---
apiVersion: pingcap.com/v1alpha1
kind: BackupSchedule
metadata:
name: demo1-backup-schedule-s3
namespace: test1
spec:
#maxBackups: 5
#pause: true
maxReservedTime: "3h"
schedule: "*/2 * * * *"
serviceAccount: tidb-backup-manager
backupTemplate:
backupType: full
br:
cluster: demo1
sendCredToTikv: false
clusterNamespace: test1
# logLevel: info
# statusAddr: ${status_addr}
# concurrency: 4
# rateLimit: 0
# timeAgo: ${time}
# checksum: true
from:
host: ${tidb_host}
port: ${tidb_port}
user: ${tidb_user}
secretName: backup-demo1-tidb-secret
s3:
provider: aws
region: us-west-1
bucket: my-bucket
prefix: my-folder
定时全量备份创建完成后,可以通过以下命令查看定时全量备份的状态:
kubectl get bks -n test1 -o wide
查看定时全量备份下面所有的备份条目:
kubectl get bk -l tidb.pingcap.com/backup-schedule=demo1-backup-schedule-s3 -n test1
从以上两个示例可知,backupSchedule
的配置由两部分组成。一部分是 backupSchedule
独有的配置,另一部分是 backupTemplate
。backupTemplate
指定 S3 兼容存储相关的配置,该配置与 Ad-hoc 全量备份到兼容 S3 的存储配置完全一样,可参考使用 BR 备份数据到 Amazon S3 的存储。下面介绍 backupSchedule
独有的配置项:
.spec.maxBackups
:一种备份保留策略,决定定时备份最多可保留的备份个数。超过该数目,就会将过时的备份删除。如果将该项设置为0
,则表示保留所有备份。.spec.maxReservedTime
:一种备份保留策略,按时间保留备份。例如将该参数设置为24h
,表示只保留最近 24 小时内的备份条目。超过这个时间的备份都会被清除。时间设置格式参考func ParseDuration
。如果同时设置最大备份保留个数和最长备份保留时间,则以最长备份保留时间为准。.spec.schedule
:Cron 的时间调度格式。具体格式可参考 Cron。.spec.pause
:该值默认为false
。如果将该值设置为true
,表示暂停定时调度。此时即使到了调度时间点,也不会进行备份。在定时备份暂停期间,备份 Garbage Collection (GC) 仍然正常进行。将true
改为false
则重新开启定时全量备份。