--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/