Use this file to discover all available pages before exploring further.
TiDB Operator is the official Kubernetes operator for TiDB. It manages the full lifecycle of TiDB clusters — provisioning, scaling, upgrading, backup, and recovery — through Kubernetes Custom Resources. You interact with your cluster by applying YAML manifests rather than running manual commands on individual nodes.
TiDB Operator automates operations that would otherwise require significant manual coordination across TiDB, TiKV, PD, and TiFlash components. It is the recommended approach for any Kubernetes-based deployment.
Watch the pods come up. TiDB Operator starts PD first, then TiKV, then TiDB:
kubectl -n tidb-cluster get pods --watch
The cluster is ready when all pods show Running status and their containers are ready (e.g., 1/1). This typically takes 3–5 minutes.Check the overall cluster status:
TiDB Operator creates a ClusterIP service for TiDB by default. Other pods in the cluster can connect using the service DNS name:
# Service name follows the pattern: <cluster-name>-tidb.<namespace>mysql -h basic-tidb.tidb-cluster -P 4000 -u root
Connect from a temporary pod for quick testing:
kubectl run -it --rm mysql-client \ --image=mysql:8.0 \ --restart=Never \ --namespace=tidb-cluster \ -- mysql -h basic-tidb -P 4000 -u root
Change the TiDB service type to LoadBalancer or NodePort to expose it externally.LoadBalancer (recommended for cloud providers):Update spec.tidb.service.type in your TidbCluster manifest:
tidb: service: type: LoadBalancer
Apply the change and retrieve the external IP:
kubectl apply -f tidb-cluster.yamlkubectl -n tidb-cluster get svc basic-tidb
Once the EXTERNAL-IP is assigned:
mysql -h <EXTERNAL-IP> -P 4000 -u root
Port-forward (for local access without a LoadBalancer):
TiDB Operator reconciles the desired state you declare in the TidbCluster resource. To scale, update the replicas field and re-apply.Scale TiDB to 3 replicas:
Scaling TiKV down (reducing replicas) triggers data migration to ensure replicas remain balanced. Do not interrupt the cluster during a scale-down operation. Monitor progress with kubectl -n tidb-cluster get tidbcluster basic until the status returns to Normal.
TiDB Operator creates PersistentVolumeClaims for PD, TiKV, and TiFlash. By default, it uses your cluster’s default StorageClass. To specify a storage class explicitly, add storageClassName to each component:
For production deployments, use a StorageClass backed by local NVMe SSDs or a high-performance block storage service. Avoid using network-attached storage for TiKV, as latency directly affects write performance.
The pvReclaimPolicy: Retain setting in the TidbCluster spec preserves PersistentVolumes when pods are deleted, protecting data during maintenance. Set it to Delete only in development environments where data loss is acceptable.
To upgrade to a new TiDB version, update the spec.version field in your TidbCluster manifest:
spec: version: v8.2.0
Apply the change:
kubectl apply -f tidb-cluster.yaml
TiDB Operator performs a rolling upgrade — it upgrades components in order (PD → TiKV → TiDB) and waits for each to be healthy before proceeding. Monitor the upgrade:
kubectl -n tidb-cluster get pods --watchkubectl -n tidb-cluster get tidbcluster basic
TiDB Operator does not support downgrading to a previous version. Take a backup before upgrading a production cluster.