title | summary | category |
---|---|---|
恢复 Kubernetes 上的 TiDB 集群数据 |
使用 TiDB Lightning 快速恢复 Kubernetes 上的 TiDB 集群数据。 |
how-to |
本文介绍了如何使用 TiDB Lightning 快速恢复 Kubernetes 上的 TiDB 集群数据。
TiDB Lightning 包含两个组件:tidb-lightning 和 tikv-importer。在 Kubernetes 上,tikv-importer 位于单独的 Helm chart 内,被部署为一个副本数为 1 (replicas=1
) 的 StatefulSet
;tidb-lightning 位于单独的 Helm chart 内,被部署为一个 Job
。
为了使用 TiDB Lightning 恢复数据,tikv-importer 和 tidb-lightning 都必须分别部署。
可以通过 tikv-importer
Helm chart 来部署 tikv-importer,示例如下:
-
确保 PingCAP Helm 库是最新的:
{{< copyable "shell-regular" >}}
helm repo update
{{< copyable "shell-regular" >}}
helm search tikv-importer -l
-
获取默认的
values.yaml
文件以方便自定义:{{< copyable "shell-regular" >}}
helm inspect values pingcap/tikv-importer --version=<chart-version> > values.yaml
-
修改
values.yaml
文件以指定目标 TiDB 集群。示例如下:clusterName: demo image: pingcap/tidb-lightning:v3.0.8 imagePullPolicy: IfNotPresent storageClassName: local-storage storage: 20Gi pushgatewayImage: prom/pushgateway:v0.3.1 pushgatewayImagePullPolicy: IfNotPresent config: | log-level = "info" [metric] job = "tikv-importer" interval = "15s" address = "localhost:9091"
clusterName
必须匹配目标 TiDB 集群。 -
部署 tikv-importer:
{{< copyable "shell-regular" >}}
helm install pingcap/tikv-importer --name=<cluster-name> --namespace=<namespace> --version=<chart-version> -f values.yaml
注意:
tikv-importer 必须与目标 TiDB 集群安装在相同的命名空间中。
使用如下命令获得 TiDB Lightning 的默认配置:
{{< copyable "shell-regular" >}}
helm inspect values pingcap/tidb-lightning --version=<chart-version> > tidb-lightning-values.yaml
tidb-lightning Helm chart 支持恢复本地或远程的备份数据。
-
本地模式:
本地模式要求 Mydumper 备份数据位于其中一个 Kubernetes 节点上。要启用该模式,你需要将
dataSource.local.nodeName
设置为该节点名称,将dataSource.local.hostPath
设置为 Mydumper 备份数据目录路径,该路径中需要包含名为metadata
的文件。 -
远程模式:
与本地模式不同,远程模式需要使用 rclone 将 Mydumper 备份 tarball 文件从网络存储中下载到 PV 中。远程模式能在 rclone 支持的任何云存储下工作,目前已经有以下存储进行了相关测试:Google Cloud Storage (GCS)、AWS S3 和 Ceph Object Storage。
使用远程模式恢复备份数据的步骤如下:
-
确保
values.yaml
中的dataSource.local.nodeName
和dataSource.local.hostPath
被注释掉。 -
新建一个包含 rclone 配置的
Secret
。rclone 配置示例如下。一般只需要配置一种云存储。有关其他的云存储,请参考 rclone 官方文档。和使用 BR 和 Mydumper 进行数据恢复时一样,使用 AWS S3 作为后端存储时,同样存在三种权限授予方式,参考使用 BR 工具备份 AWS 上的 TiDB 集群。在使用不同的权限授予方式时,需要使用不用的配置。-
使用 AWS S3 AccessKey 和 SecretKey 权限授予方式,或者使用 Ceph、GCS 作为存储后端时:
{{< copyable "" >}}
apiVersion: v1 kind: Secret metadata: name: cloud-storage-secret type: Opaque stringData: rclone.conf: | [s3] type = s3 provider = AWS env_auth = false access_key_id = <my-access-key> secret_access_key = <my-secret-key> region = us-east-1 [ceph] type = s3 provider = Ceph env_auth = false access_key_id = <my-access-key> secret_access_key = <my-secret-key> endpoint = <ceph-object-store-endpoint> region = :default-placement [gcs] type = google cloud storage # 该服务账号必须被授予 Storage Object Viewer 角色。 # 该内容可以通过 `cat <service-account-file.json> | jq -c .` 命令获取。 service_account_credentials = <service-account-json-file-content>
-
使用 AWS S3 IAM 绑定 Pod 的授权方式或者 AWS S3 IAM 绑定 ServiceAccount 授权方式时,可以省略
s3.access_key_id
以及 `s3.secret_access_key:{{< copyable "" >}}
apiVersion: v1 kind: Secret metadata: name: cloud-storage-secret type: Opaque stringData: rclone.conf: | [s3] type = s3 provider = AWS env_auth = true access_key_id = secret_access_key = region = us-east-1
使用你的实际配置替换上述配置中的占位符,并将该文件存储为
secret.yaml
。然后通过kubectl apply -f secret.yaml -n <namespace>
命令创建该Secret
。
-
-
将
dataSource.remote.storageClassName
设置为 Kubernetes 集群中现有的一个存储类型。
-
部署 TiDB Lightning 的方式根据不同的权限授予方式及存储方式,有不同的情况。
-
使用 AWS S3 AccessKey 和 SecretKey 权限授予方式,或者使用 Ceph,GCS 作为存储后端时,运行以下命令部署 TiDB Lightning:
{{< copyable "shell-regular" >}}
helm install pingcap/tidb-lightning --name=<tidb-lightning-release-name> --namespace=<namespace> --set failFast=true -f tidb-lightning-values.yaml --version=<chart-version>
-
使用 AWS S3 IAM 绑定 Pod 的授权方式时,需要做以下步骤:
-
创建 IAM 角色:
可以参考 AWS 官方文档来为账号创建一个 IAM 角色,并且通过 AWS 官方文档为 IAM 角色赋予需要的权限。由于
Lightning
需要访问 AWS 的 S3 存储,所以这里给 IAM 赋予了AmazonS3FullAccess
的权限。 -
修改 tidb-lightning-values.yaml, 找到字段
annotations
,增加 annotationiam.amazonaws.com/role: arn:aws:iam::123456789012:role/user
。 -
部署 Tidb-Lightning:
{{< copyable "shell-regular" >}}
helm install pingcap/tidb-lightning --name=<tidb-lightning-release-name> --namespace=<namespace> --set failFast=true -f tidb-lightning-values.yaml --version=<chart-version>
注意:
arn:aws:iam::123456789012:role/user
为步骤 1 中创建的 IAM 角色。
-
-
使用 AWS S3 IAM 绑定 ServiceAccount 授权方式时:
-
在集群上为服务帐户启用 IAM 角色:
可以参考 AWS 官方文档 开启所在的 EKS 集群的 IAM 角色授权。
-
创建 IAM 角色:
可以参考 AWS 官方文档创建一个 IAM 角色,为角色赋予
AmazonS3FullAccess
的权限,并且编辑角色的Trust relationships
。 -
绑定 IAM 到 ServiceAccount 资源上:
{{< copyable "shell-regular" >}}
kubectl annotate sa <servie-account> -n eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user
-
部署 Tidb-Lightning:
{{< copyable "shell-regular" >}}
helm install pingcap/tidb-lightning --name=<tidb-lightning-release-name> --namespace=<namespace> --set-string failFast=true,serviceAccount=<servie-account> -f tidb-lightning-values.yaml --version=<chart-version>
注意:
arn:aws:iam::123456789012:role/user
为步骤 1 中创建的 IAM 角色。 为 tidb-lightning 使用的 ServiceAccount,默认为 default。
-
当 TiDB Lightning 未能成功恢复数据时,不能简单地直接重启进程,必须进行手动干预,否则将很容易出现错误。因此,tidb-lightning 的 Job
重启策略被设置为 Never
。
如果 TiDB Lightning 未能成功恢复数据,需要采用以下步骤进行手动干预:
-
运行
kubectl delete job -n <namespace> <tidb-lightning-release-name>-tidb-lightning
,删除 lightningJob
。 -
运行
helm template pingcap/tidb-lightning --name <tidb-lightning-release-name> --set failFast=false -f tidb-lightning-values.yaml | kubectl apply -n <namespace> -f -
,重新创建禁用failFast
的 lightningJob
。 -
当 lightning pod 重新运行时,在 lightning 容器中执行
kubectl exec -it -n <namesapce> <tidb-lightning-pod-name> sh
命令。 -
运行
cat /proc/1/cmdline
,获得启动脚本。 -
参考故障排除指南,对 lightning 进行诊断。
目前,TiDB Lightning 只能在线下恢复数据。当恢复过程结束、TiDB 集群需要向外部应用提供服务时,可以销毁 TiDB Lightning 以节省开支。
删除 tikv-importer 的步骤:
- 运行
helm delete <tikv-importer-release-name> --purge
。
删除 tidb-lightning 的方法:
- 运行
helm delete <tidb-lightning-release-name> --purge
。