周期表的清理逻辑设计
这是学习笔记的第 2065 篇文章
今天做了下周期表清理的设计,从实践的效果来看还不错。现在线上环境有差不多50多个周期表要统一管理,随着这个管理的规模扩大,对于生命周期的管理也迫在眉睫。
一种比较尴尬的情况就是看到库里面存在大量的过期数据表,但是删除起来又不是很方便,随着偷懒这些表就这么慢慢积累下来了。有一套环境有6000多张表,其实按照保留周期需要的表只有800多个,剩下的过期周期表都应该删除。
整个周期表的清理逻辑做了下面的设计:
1.以API的方式设计
参数设计:
ip_addr
db_port
Start_time
End_time
Table_schema
Table_name
Code: cycle_table_list
2.根据配置中的保留信息得到过期的列表
存在不连续的周期表,如果是20190101,20190103这样不连续的周期表,需要保证程序的健壮性
更早的周期表,如果我们扫描的周期是近2个月,2个月之前的过期周期表也应该被覆盖
3.检查归档数据库是否存在
归档数据库是整个设计的核心,即数据不是直接drop,而是做了转储。整个判断的逻辑如下:
如果不存在,则触发逻辑创建归档数据库,以_arch结尾
如果存在,触发归档处理,执行rename操作将过期的表移动到归档数据库中,
所以数据库中的列表如下::
chatlog_db
4.归档数据的处理
归档数据库做定时清理,设置清理的频度
归档数据的大数据下沉
5.数据清理的存储日志
设计清理日志记录表,对于操作记录(周期性检测任务,数据库检测任务,rename操作)
每一张表需要一条记录
做了一个对接,那个钉子户环境清理之后,归档数据库中的表有近5000张,舒服多了。
| t_test_up_20190607 |test_up_20190608 |test_up_20190609 |