Deploy TiDB on Google Cloud
This tutorial is designed to be directly run in Google Cloud Shell.
It takes you through the following steps:
- Launch a new 3-node Kubernetes cluster (optional)
- Install the Helm package manager for Kubernetes
- Deploy the TiDB Operator
- Deploy your first TiDB cluster
- Connect to the TiDB cluster
- Scale out the TiDB cluster
- Shut down the Kubernetes cluster (optional)
Select a project
This tutorial launches a 3-node Kubernetes cluster of n1-standard-1
machines. Pricing information can be found here.
Please select a project before proceeding:
Enable API access
This tutorial requires use of the Compute and Container APIs. Please enable them before proceeding:
Configure gcloud defaults
This step defaults gcloud to your preferred project and zone, which simplifies the commands used for the rest of this tutorial:
gcloud config set project {{project-id}}
gcloud config set compute/zone us-west1-a
Launch a 3-node Kubernetes cluster
It's now time to launch a 3-node kubernetes cluster! The following command launches a 3-node cluster of n1-standard-1
machines.
It takes a few minutes to complete:
gcloud container clusters create tidb
Once the cluster has launched, set it to be the default:
gcloud config set container/cluster tidb
The last step is to verify that kubectl
can connect to the cluster, and all three machines are running:
kubectl get nodes
If you see Ready
for all nodes, congratulations! You've setup your first Kubernetes cluster.
Install Helm
Helm is the package manager for Kubernetes, and is what allows us to install all of the distributed components of TiDB in a single step. Helm requires both a server-side and a client-side component to be installed.
Install helm
:
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash
Copy helm
to your $HOME
directory so that it persists after the Cloud Shell reaches its idle timeout:
mkdir -p ~/bin && \
cp /usr/local/bin/helm ~/bin && \
echo 'PATH="$PATH:$HOME/bin"' >> ~/.bashrc
Helm also needs a couple of permissions to work properly:
kubectl apply -f ./manifests/tiller-rbac.yaml && \
helm init --service-account tiller --upgrade
It takes a minute for helm to initialize tiller
, its server component:
watch "kubectl get pods --namespace kube-system | grep tiller"
When you see Running
, it's time to hit Ctrl+C and proceed to the next step!
Add Helm repo
Helm repo (https://charts.pingcap.org/
) houses PingCAP managed charts, such as tidb-operator, tidb-cluster and tidb-backup, etc. Add and check the repo with following commands:
helm repo add pingcap https://charts.pingcap.org/ && \
helm repo list
Then you can check the available charts:
helm repo update
helm search tidb-cluster -l
helm search tidb-operator -l
Deploy TiDB Operator
Note that <chartVersion>
is used in the rest of the document to represent the chart version, e.g. v1.0.0
.
The first TiDB component we are going to install is the TiDB Operator, using a Helm Chart. TiDB Operator is the management system that works with Kubernetes to bootstrap your TiDB cluster and keep it running. This step assumes you are in the tidb-operator
working directory:
kubectl apply -f ./manifests/crd.yaml && \
kubectl apply -f ./manifests/gke/persistent-disk.yaml && \
helm install pingcap/tidb-operator -n tidb-admin --namespace=tidb-admin --version=<chartVersion>
We can watch the operator come up with:
watch kubectl get pods --namespace tidb-admin -o wide
When you see both tidb-scheduler and tidb-controller-manager are Running
, press Ctrl+C and proceed to launch a TiDB cluster!
Deploy your first TiDB cluster
Now with a single command we can bring-up a full TiDB cluster:
helm install pingcap/tidb-cluster -n demo --namespace=tidb --set pd.storageClassName=pd-ssd,tikv.storageClassName=pd-ssd --version=<chartVersion>
It takes a few minutes to launch. You can monitor the progress with:
watch kubectl get pods --namespace tidb -o wide
The TiDB cluster includes 2 TiDB pods, 3 TiKV pods, and 3 PD pods. When you see all pods Running
, it's time to Ctrl+C and proceed forward!
Connect to the TiDB cluster
There can be a small delay between the pod being up and running, and the service being available. You can watch list services available with:
watch "kubectl get svc -n tidb"
When you see demo-tidb
appear, you can Ctrl+C. The service is ready to connect to!
To connect to TiDB within the Kubernetes cluster, you can establish a tunnel between the TiDB service and your Cloud Shell. This is recommended only for debugging purposes, because the tunnel will not automatically be transferred if your Cloud Shell restarts. To establish a tunnel:
kubectl -n tidb port-forward svc/demo-tidb 4000:4000 &>/tmp/port-forward.log &
From your Cloud Shell:
sudo apt-get install -y mysql-client && \
mysql -h 127.0.0.1 -u root -P 4000
Try out a MySQL command inside your MySQL terminal:
select tidb_version();
If you did not specify a password in helm, set one now:
SET PASSWORD FOR 'root'@'%' = '<change-to-your-password>';
Congratulations, you are now up and running with a distributed TiDB database compatible with MySQL!
Scale out the TiDB cluster
With a single command we can easily scale out the TiDB cluster. To scale out TiKV:
helm upgrade demo pingcap/tidb-cluster --set pd.storageClassName=pd-ssd,tikv.storageClassName=pd-ssd,tikv.replicas=5 --version=<chartVersion>
Now the number of TiKV pods is increased from the default 3 to 5. You can check it with:
kubectl get po -n tidb
Accessing the Grafana dashboard
To access the Grafana dashboards, you can create a tunnel between the Grafana service and your shell. To do so, use the following command:
kubectl -n tidb port-forward svc/demo-grafana 3000:3000 &>/dev/null &
In Cloud Shell, click on the Web Preview button and enter 3000 for the port. This opens a new browser tab pointing to the Grafana dashboards. Alternatively, use the following URL https://ssh.cloud.google.com/devshell/proxy?port=3000 in a new tab or window.
If not using Cloud Shell, point a browser to localhost:3000
.
Destroy the TiDB cluster
When the TiDB cluster is not needed, you can delete it with the following command:
helm delete demo --purge
The above commands only delete the running pods, the data is persistent. If you do not need the data anymore, you should run the following commands to clean the data and the dynamically created persistent disks:
kubectl delete pvc -n tidb -l app.kubernetes.io/instance=demo,app.kubernetes.io/managed-by=tidb-operator && \
kubectl get pv -l app.kubernetes.io/namespace=tidb,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/instance=demo -o name | xargs -I {} kubectl patch {} -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
Shut down the Kubernetes cluster
Once you have finished experimenting, you can delete the Kubernetes cluster with:
gcloud container clusters delete tidb