--2022-09-13 春雷

1、前言

18年4月，TiDB在公司开始落地，至今已经4年多了，随着业务的快速接入，截至目前已经运维着超120套TiDB集群，算是体量已经很庞大了。

2、周期

TiDB在公司，经历了几个周期，如下图：

从最初的测试、引入，到大规模迁移，集群数爆炸式增长，到TiDB运维体系整体完善，引入套餐与账单，再到疫情来临，资源紧张，需要进行存储空间优化、小集群优化，到了精细化运维的阶段，再到后面计划的云化阶段，来真正释放资源。

3、TiDB成本

TiDB的一个线上集群的节点情况入下图：

TiDB节点 x 3、PD节点 x 3、TiKV节点 x 3、监控节点 x 1

这样一套TiDB集群的资源就需要：

7个8核16G虚拟机 （单机单实例）

3台40核256G3.5T闪存卡的物理机 (单机多实例部署)

综上，TiDB集群至少需要10个节点左右才能进行部署，成本比较高。

如果一套TiDB上线半年内没有很大的增长，例如几十G，那么耗费的资源与收益就不成正比了。

4、问题

当前运维了大量的TiDB，从资源合理性角度 或精细化运维的角度，有如下问题：

【问题】：新的业务上TiDB，集群创建了半年，存储空间还小于100G，面对10个节点的TiDB，这种存是低于接入门槛的资源浪费情况，且与TiDB的运维规范不符

【方案】：

咨询业务增长情况，如果可以保证近期有大量增长，则可以继续保留

如果近期无大量增长，则回迁MySQL，可利用TiDB CDC来进行回迁

【问题】：已经上线有一定时间的集群，上线了很多大表，但有些表是只需要存储近期的数据即可，即历史数据可以清理，但是目前没有清理的，这种是无用数据占大量存储资源的浪费情况

【方案】：

与业务咨询，确认哪些表的数据可以清理

业务自己写程序清理

DBA提供批量清理的方式，业务添加清理任务、保留时间即可自动清理

【问题】：已经上线了一定时间的集群，表无变更，不查询，这种是业务下线集群未下线的浪费情况

【方案】：

与业务咨询，确认是否可以整体删除、集群下线

DBA开发生命周期，自动扫描出未用的集群，通知业务，进行自动化下线

5、工作

面对如上问题，近期组内进行了精细化运营的相关工作：

确定迁移MySQL方案：

引入TiCDC，验证TiDB迁移至MySQL方案

开发生命周期相关程序：

自动获取低负载的集群

自动获取低存储的集群

自动通知业务

自动化回收、下线集群

开发数据自动清理任务：

利用pt工具，实现自动化分批清理

支持单次清理、定期清理

调研TiDB云化实现方式：

容器化部署TiDB的可行性

TiDB的容器部署流程测试

TiDB的容器部署性能测试

6、生命周期

生命周期的概念：是指数据库从申请到使用到下线的整个生命周期的记录。

7、TiDB生命周期

7.1、空闲集群判断条件

条件

判断阈值

表更新时间

半年内无更新

集群运行时间

运行时间半年以上

六个月以内连接数

无连接

集群qps

连续半年小于70000则为空闲集群

半年内工单数量

半年内无工单

自助查询判断

半年内自助查询次数

7.2、表更新时间

表的更新时间，TiDB是不太好实现的，在MySQL里面，我们可以看文件的更新时间来确认表的更新时间。

TiDB里面有一个命令：SHOW STATS_META，可以查看表的总行数以及修改的行数等信息。

语法元素

说明

db_name

数据库名

table_name

表名

partition_name

分区名

update_time

更新时间

modify_count

修改的行数

row_count

总行数

以为这个update_time可以作为表的更新时间，但实际看是不可以的，这个更新时间：

在表结构变更时会变化

在analyze之后也会变

后面我们再看看能否通过tidb 的相关SQL记录来实现吧，当前只能先忽略了。

7.3、实现

7.3.1、实现架构

通过获取集群的相关信息，判定集群是否为空闲集群

空闲集群则进行集群下线、备份保留等

7.3.2、平台实现

【集群使用度】：

【使用度详情】：

【自动化下线】：

8、收益

通过TiDB生命周期的功能，统计收益如下：

下线未用的集群：20套

总存储： 8.2T+

总节点：224个

tikv 60个

tidb 80个

pd 60个

prometheus 20个

Grafana 20个

tiflash 4个

号外：

推荐大家关注NewSQL公众号，关注NewSQL Group社区

网站：https://newsqlgroup.com/