TiDB生命周期
作者: 18515065291
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社区