- Get Started
- Deploy TiDB Cluster
- Deploy Heterogeneous Cluster
- Deploy TiFlash
- Deploy TiCDC
- Deploy TiDB Binlog
- Deploy Multiple Sets of TiDB Operator
- Deploy Monitoring
- Upgrade TiDB Cluster
- Upgrade TiDB Operator
- Perform a Canary Upgrade
- Pause Sync of TiDB Cluster
- Scale TiDB Cluster
- Backup and Restore
- Grant Permissions to Remote Storage
- Backup and Restore with S3-Compatible Storage
- Backup and Restore with GCS
- Backup and Restore with Persistent Volumes
- Restart a TiDB Cluster
- Maintain a Kubernetes Node
- View TiDB Logs
- Configure Automatic Failover
- Destroy a TiDB Cluster
- Migrate from Helm 2 to Helm 3
- Disaster Recovery
- Import Data
- Sysbench Performance Test
- API References
- Cheat Sheet
- Log Collection
- Monitoring and Alert on Kubernetes
- Release Notes
This document describes how to grant permissions to access remote storage for backup and restore. During the backup process, TiDB cluster data is backed up to the remote storage. During the restore process, the backup data is restored from the remote storage to the TiDB cluster.
Amazon Web Service (AWS) provides different methods to grant permissions for different types of Kubernetes clusters. This document describes the following three methods.
The AWS client can read
AWS_SECRET_ACCESS_KEY from the process environment variables to obtain the associated user or role permissions.
s3-secret secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
Create an IAM role.
First, create an IAM User for your account.
Then, Give the required permission to the IAM role you have created. Refer to Adding and Removing IAM Identity Permissions for details.
BackupCR needs to access the Amazon S3 storage, the IAM role is granted the
Associate IAM with the TiKV Pod:
When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
kubectl edit tc demo1 -n test1
spec.tikv.annotations, add this annotation to it:
iam.amazonaws.com/role: arn:aws:iam::123456789012:role/user, and exit the editor. After the TiKV Pod is restarted, check whether the Pod has the annotation.
arn:aws:iam::123456789012:role/user is the IAM role created in Step 1.
When you use this method to grant permissions, you can create the EKS cluster and deploy TiDB Operator and the TiDB cluster.
Enable the IAM role for the
serviceAccountin the cluster:
Refer to AWS documentation.
Create the IAM role:
Create an IAM role and grant the
AmazonS3FullAccesspermissions to the role. Edit the role's
Associate IAM with the
kubectl annotate sa tidb-backup-manager -n eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
ServiceAccountwith the TiKV Pod:
kubectl edit tc demo1 -n test1
Modify the value of
tidb-backup-manager. After the TiKV Pod is restarted, check whether the Pod's
arn:aws:iam::123456789012:role/user is the IAM role created in Step 2.
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 for details.
kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1