周期表的清理逻辑设计

这是学习笔记的第 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 chatlog_db_arch

4.归档数据的处理

归档数据库做定时清理，设置清理的频度

归档数据的大数据下沉

5.数据清理的存储日志

设计清理日志记录表，对于操作记录（周期性检测任务，数据库检测任务，rename操作）

每一张表需要一条记录

做了一个对接，那个钉子户环境清理之后，归档数据库中的表有近5000张，舒服多了。

| t_test_up_20190607 | | t_test_up_20190608 | | t_test_up_20190609 | +-----------------------------+ 4929 rows in set (0.01 sec)