说明
- 仅记录操作过程和部署过程
- 操作系统使用的
CentOS-7.6.1810 x86_64
- 虚拟机配置
4CPU 8G内存 30G系统盘 20G数据盘A 5G数据盘B
- Kubernetes集群版本
v1.14.4
- 使用本地PV作为数据存储
- TiDB-Operator版本
v1.0.0
- TiDB组件版本
v3.0.1
服务器拓扑
服务器IP | 部署实例 |
---|---|
172.16.80.201 | TiKv*1 TiDB*1 PD*1 |
172.16.80.202 | TiKv*1 TiDB*1 PD*1 |
172.16.80.203 | TiKv*1 TiDB*1 PD*1 |
准备工作
安装Helm
二进制安装
1 | wget -O - https://get.helm.sh/helm-v2.14.1-linux-amd64.tar.gz | tar xz linux-amd64/helm |
创建RBAC
1 | cat << EOF | kubectl apply -f - |
安装Helm服务端
1 | helm init --tiller-image gcr.azk8s.cn/google_containers/tiller:v2.14.1 \ |
检查部署结果
查看Pod状态
1 | kubectl -n kube-system get pod -l app=helm,name=tiller |
输出示例
1 | NAME READY STATUS RESTARTS AGE |
查看Helm版本信息
1 | helm version |
输出示例
1 | Client: &version.Version{SemVer:"v2.14.1", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} |
添加Helm Repo
1 | helm repo add pingcap https://charts.pingcap.org/ |
更新helm缓存
1 | helm repo update |
查看TiDB-Operator版本
1 | helm search pingcap -l |
输出示例
1 | NAME CHART VERSION APP VERSION DESCRIPTION |
配置本地PV
参考【Kubernetes创建本地PV】
修改ext4挂载选项为defaults,nodelalloc,noatime
示例如下
1 | UUID=f8727d20-3ef9-4f83-b865-25943bc342a6 /mnt/disks/f8727d20-3ef9-4f83-b865-25943bc342a6 ext4 defaults,nodelalloc,noatime 0 2 |
创建CRD
1 | kubectl apply -f https://raw.githubusercontent.com/pingcap/tidb-operator/master/manifests/crd.yaml |
部署TiDB-Operator
创建工作目录
1 | mkdir -p /home/TiDB |
下载TiDB-Operator Chart包
1 | cd /home/TiDB |
解压Chart包
1 | tar xzf tidb-operator-v1.0.0.tgz |
编辑values.yaml
1 | vim tidb-operator/values.yaml |
修改如下
1 | # Default values for tidb-operator |
部署Operator
1 | helm install pingcap/tidb-operator \ |
查看Operator部署情况
1 | kubectl -n tidb-admin get pod -l app.kubernetes.io/name=tidb-operator |
部署TiDB-Cluster
创建工作目录
1 | mkdir -p /home/TiDB |
下载Chart包
1 | cd /home/TiDB |
解压Chart包
1 | tar xzf tidb-cluster-v1.0.0.tgz |
编辑values.yaml
配置含义请看这里【Kubernetes 上的 TiDB 集群配置】
1 | vim tidb-cluster/values.yaml |
修改后如下
1 | # Default values for tidb-cluster. |
部署Cluster
1 | helm install pingcap/tidb-cluster \ |
查看Cluster部署情况
1 | kubectl -n tidb get pods -l app.kubernetes.io/instance=tidb-cluster |
输出示例
1 | NAME READY STATUS RESTARTS AGE |
访问TiDB
TiDB兼容MySQL,因此能直接使用MySQL客户端连接TiDB集群
这里使用
mysql-community-client-5.7.27-1.el7
作为客户端程序
获取TiDB Service信息
1 | kubectl -n tidb get svc -l app.kubernetes.io/component=tidb |
输出示例
1 | NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE |
从输出示例,可以看到tidb-cluster-tidb
是NodePort
类型,业务端口4000
被映射为节点的30944
端口,直接通过此端口即可访问TiDB。
登录TiDB
默认集群部署完成后,root用户是无密码的
1 | mysql -u root -P 30944 -h k8s-master |
简单查询
查看系统表mysql.tidb
1 | mysql> select VARIABLE_NAME,VARIABLE_VALUE from mysql.tidb; |
输出示例
1 | +--------------------------+--------------------------------------------------------------------------------------------------+ |
查看系统变量
1 | mysql> show global variables like '%tidb%'; |
输出示例
1 | +-------------------------------------+-----------------------+ |
查看监控信息
- TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。
- 在通过 TiDB Operator 创建新的 TiDB 集群时,对于每个 TiDB 集群,会同时创建、配置一套独立的监控系统,与 TiDB 集群运行在同一 Namespace,包括 Prometheus 和 Grafana 两个组件。
- 监控数据默认没有持久化,如果由于某些原因监控容器重启,已有的监控数据会丢失。可以在
values.yaml
中设置monitor.persistent
为true
来持久化监控数据。
获取监控端口
1 | kubectl -n tidb get svc -l app.kubernetes.io/component=monitor |
输出示例
1 | NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE |
访问监控
可以看到监控服务都是NodePort类型,直接通过节点端口即可访问监控服务
更新和升级
TiDB-Operator
当新版本 tidb-operator 发布,只要更新 values.yaml
中的 operatorImage
然后执行上述命令就可以。但是安全起见,最好从新版本 tidb-operator
chart 中获取新版本 values.yaml
并和旧版本 values.yaml
合并生成新的 values.yaml
,然后升级。
TiDB Operator 是用来管理 TiDB 集群的,也就是说,如果 TiDB 集群已经启动并正常运行,你甚至可以停掉 TiDB Operator,而 TiDB 集群仍然能正常工作,直到你需要维护 TiDB 集群,比如伸缩、升级等等。
升级TiDB-Operator
1 | helm upgrade tidb-operator pingcap/tidb-operator --version=v1.0.0 -f /home/tidb/tidb-operator/values.yaml |
Kubernetes集群版本升级
当你的 Kubernetes 集群有版本升级,请确保 kubeSchedulerImageTag
与之匹配。默认情况下,这个值是由 Helm 在安装或者升级过程中生成的,要修改它你需要执行 helm upgrade
。
TiDB-Cluster
滚动更新 TiDB 集群时,会按 PD、TiKV、TiDB 的顺序,串行删除 Pod,并创建新版本的 Pod,当新版本的 Pod 正常运行后,再处理下一个 Pod。
滚动升级过程会自动处理 PD、TiKV 的 Leader 迁移与 TiDB 的 DDL Owner 迁移。因此,在多节点的部署拓扑下(最小环境:PD 3、TiKV 3、TiDB * 2),滚动更新 TiKV、PD 不会影响业务正常运行。
对于有连接重试功能的客户端,滚动更新 TiDB 同样不会影响业务。
对于无法进行重试的客户端,滚动更新 TiDB 则会导致连接到被关闭节点的数据库连接失效,造成部分业务请求失败。对于这类业务,推荐在客户端添加重试功能或在低峰期进行 TiDB 的滚动升级操作。
滚动更新可以用于升级 TiDB 版本,也可以用于更新集群配置。
更新TiDB-Cluster配置
默认条件下,修改配置文件不会自动应用到 TiDB 集群中,只有在实例重启时,才会重新加载新的配置文件。
操作步骤如下
修改集群的
values.yaml
文件,将enableConfigMapRollout
的值设为true
修改集群的
values.yaml
文件中需要调整的集群配置项,例如修改pd.replicas
、tidb.replicas
、tikv.replicas
来进行水平扩容和缩容执行
helm upgrade
命令升级1
helm upgrade tidb-cluster pingcap/tidb-cluster -f /home/tidb/tidb-cluster/values.yaml --version=v1.0.0
查看升级进度
1
watch -n 1 'kubectl -n tidb get pod -o wide'
升级 TiDB-Cluster 版本
修改集群的
values.yaml
文件中的tidb.image
、tikv.image
、pd.image
的值为新版本镜像;执行
helm upgrade
命令进行升级:1
helm upgrade tidb-cluster pingcap/tidb-cluster -f /home/tidb/tidb-cluster/values.yaml --version=v1.0.0
查看升级进度
1
watch -n 1 'kubectl -n tidb get pod -o wide'
注意:
- 将
enableConfigMapRollout
特性从关闭状态打开时,即使没有配置变更,也会触发一次 PD、TiKV、TiDB 的滚动更新。 - 目前 PD 的
scheduler
和replication
配置(values.yaml
中的maxStoreDownTime
和maxReplicas
字段)在集群安装完成后无法自动更新,需要通过 pd-ctl 手动更新。