博客 - tidb-operator生产实践之集群操作篇

前一篇文章《tidb-operator生产部署篇》已经完成了tidb-operator这个tidb集群管控工具以及生产环境tidb集群的部署，今天这篇文章继续讲述生产环境的tidb集群访问、集群扩缩容、集群升级等基本日常操作。

一、生产环境tidb访问

TiDB部署完成后要想访问有2项工作需要处理，分别是如何访问和集群初始化，下面分别来进行落地：

（1）如何访问生产环境TiDB？

如果是集群内访问分别是可以通过：pods ip、Service Cluster-IP、Service域名来访问

先看通过pods ip访问的：

# Get pods in the tidb-test namespace and filter for tidb-test
kubectl get pods -n tidb-test -o wide | grep tidb-test-tidb

# Connect to MySQL
mysql -h 10.xxx.xxx.1 -uroot -p -P4000
# Enter password:

# Welcome to the MySQL monitor. Commands end with ; or \g.
# Your MySQL connection id is 50541114
# Server version: 8.0.11-TiDB-v8.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
# Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

# Execute SQL command
select user();

+-------------------+
| user()            |
+-------------------+
| root@10.101.232.2 |
+-------------------+
1 row in set (0.00 sec)

# Exit MySQL
exit
Bye

然后基于Service Cluster-IP访问的

# Get services in the tidb-test namespace and filter for tidb-test-tidb
kubectl get services -n tidb-test -o wide | grep tidb-test-tidb

# Connect to MySQL
mysql -h 172.xxx.xxx.213 -uroot -p -P4000

# MySQL commands
select user();
exit

基于集群域名的访问，域名的组成方式：${service name}.${namespace}.svc.cluster.local

# Connect to MySQL
mysql -h tidb-test-tidb-peer.tidb-test.svc.cluster.local -uroot -p -P4000

# Enter password
# Welcome message
# Your MySQL connection id is 2630038118
# Server version: 8.0.11-TiDB-v8.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
# Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

# Execute SQL command
select user();

# Output
# +-------------------+
# | user()            |
# +-------------------+
# | root@10.101.232.2 |
# +-------------------+
# 1 row in set (0.00 sec)

# Exit MySQL
exit
# Bye

生产环境建议用哪个？

回答这个生产环境访问的问题，我是建议用域名，因为一旦service被删除重建，Cluster-IP会发生变化业务如果写死的是具体的CLuster-IP，肯定会发生故障，如果基于域名方式访问则不会有问题。

（2）初始化权限和创建库表

默认部署完成的root数据库用户的密码为空，需要及时修改，另外就是给业务创建DB，创建业务账号和赋权，然后将域名、端口、数据库用户和密码发给用户使用即可。

SET PASSWORD FOR 'root'@'%' = 'xxxx';
CREATE DATABASE user_db;
CREATE USER 'user_db_sdml'@'10.%' IDENTIFIED BY 'xxxx';
GRANT SELECT, INSERT, UPDATE, DELETE ON user_db.* TO 'user_db_sdml'@'10.%';
EXIT;

二、生产环境tidb集群扩缩容的时机以及操作方式

k8s中的tidb集群扩缩容的命令很简单，但是我们需要知道什么情况下需要去操作，下面我列出几种需要操作的情景。

（1）通过监控查看大部分的tidb/tikv的CPU、内存、硬盘使用超过Qos配置limit上限的80%，这时就需要扩容。注意一些细节点：

首先是tidb/tikv的大部分节点，而不是某一个节点跑高，单节点负载过高大部分情况是热点，基本是可以通过重启解决。单region过热重启不管用，需要用tidb 6.0的内存表或者业务+DB的多层cache来解决，后面我可以写一篇热点处理的文章给大家详细介绍。
比如大部分tikv的存储使用超过80%，这时就需要及时扩容存储，如果使用的是动态PV，可以垂直扩容(500G->1024G)，如果基于local的物理ssd盘，就需要扩容replica数量，避免磁盘写满导致的业务问题。
大部分的扩容都是水平扩容，就是将8个tikv扩容到10个或者更多。但是还有一种就是垂直扩容，这种扩容一般都是单资源跑高，比如只有mem使用比较高，快超过limit阀值，有oom的风险，这时需要修改配置，调整内存限制就好，调整的过程自动触发tidb/tikv数据编号由大到小挨个重启。

（2）缩容的话就看资源使用率，一般都是初始化集群时因业务高估自己业务流量配置过大了。

比如底层局3个tikv，肯定不能缩容到2个（无法高可用），这时需要垂直降配(比如tikv之前配置20核100G内存，降低到12核心10G)。
另外大部分就是缩容tidb/tikv的数量，注意满足tidb集群高可用的最低配置数量

操作方式

其实就是调整tidb-test.yaml中的replicas(数量)，以及QOS部分（requests、limits），以tikv为例，我们要将tikv从3个扩容到5个，修改下面的replicas 3->5即可。如果要调整cpu限制需要修改request或者limits部分，比如我们想让tikv使用更多的CPU，就可以调整limits cpu 从14核心（14000m）到20核心，调整如下：

tikv:
  baseImage: pingcap/tikv:v8.4.0
  replicas: 5  # 调整这里3->5
  # if storageClassName is not set, the default Storage Class of the Kubernetes cluster will be used
  storageClassName: local-storage
  requests:
    cpu: 6000m
    memory: 12Gi
    storage: 1760Gi
  limits:
    cpu: 20000m  # 这里调整14000->20000m
    memory: 32Gi
    storage: 1760Gi

修改后保存，然后执行应用即可

# kubectl apply -f tidb-test.yaml -n tidb-test

三、生产环境tidb集群升级

k8s环境下tidb集群升级的操作也非常简单。只需要修改tidb-test.yaml中的baseImage，生产环境建议下载对应的镜像到公司内部的镜像仓库，如果没有镜像仓库，需要k8s集群的nodes可访问外网(不太建议DB服务器出外网)，并且选择阿里云的镜像地址。

tidb:
  baseImage: pingcap/tidb:v8.4.0  # 修改之前的7.5.0->8.4.0

tikv:
  baseImage: pingcap/tikv:v8.4.0  # 修改之前的7.5.0->8.4.0

pd:
  baseImage: pingcap/pd:v8.4.0    # 修改之前的7.5.0->8.4.0

四、总结

k8s里面的tidb集群管理非常简单，就是一个yaml管所有，我们的扩缩容、升级等日常操作也就是维护tidb集群yaml变更，如果更好、更安全的变更？比如使用git来管理yaml，这样可以避免误删除，避免错误变更后无法回滚(因为修改保存后你不知道之前的配置了)，用git就可以完美解决变更风险管控问题，最终实现更快、更稳的tidb集群维护。