作者： 18515065291 原文来源：https://tidb.net/blog/d5b8af92

                              \--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、空闲集群判断条件

7.2、表更新时间

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

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

以为这个 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/

公众号：NewSQL

微信群：