周期表生命周期管理

这是学习笔记的第 2085 篇文章

对于周期表的生命周期管理，一直以来是一个不被重视的环节，听起来有些拗口，所谓的周期表就是类似日表分区表那样的数据表，在MySQL中我们和业务方算是达成了共识，把需求引导过来后，需求如雨后春笋一般都冒出来了，所以在管理中也发现了很多的潜在问题。

建表需求是一种第风险操作，而删除则是高风险操作，所以在处理方式上两者的方式就有很大的差别，比如创建周期表，我们可以提前一两周就预创建1个月~3个月的周期表。

而删除操作则是滞后的处理方式，首先我们想尽可能多的保留数据的历史信息，同时又要考虑存储情况尽可能物尽其用，在这方面能够做到的只能是平衡，而为了尽可能不出错，我们总是采取保守的方式，导致数据库立面的周期表越来越多。

创建的工作相对可控，但是删除的操作就麻烦了，我们需要谨慎处理，为了保证drop操作的可控和可回溯，我们设置了回收站的处理方式，即一个数据库会对应一个arch命名的归档库，当我们要删除周期表时，可以把要删除的表rename到arch命名的归档库里面，数据表在归档库里面，但是对于业务来说，数据是不可见的，效果跟删除了数据是相似的。

我这边设计了4个状态来追溯整个生命周期的一些阶段，笼统来说，是分为两个阶段。

第一阶段是转置，做rename操作，把表数据归档到arch归档库里面。

第二阶段是清理，做drop操作，在arch归档库开始删除操作，删除的频率不宜过于频繁。

在开始阶段，我们需要做的就是根据逻辑去提取过期的周期表。

在这个基础之上应用上面4个状态，比如表不存在，环境配置的差异导致rename操作失败，会把整个操作的失败之处都记录下来，而rename成功就会是状态MOVE_ARCH_SUCC,而提取，转置工作完成之后，就可以开始数据清理了。一般来说在清理的过程中，我们需要增加一系列的校验规则，比如对周期表的属性进行检查，确保操作完全可靠，可控。

在使用了如上的设计思路之后，完成这个功能还是很快的，在扫描了大量的环境之后，我们转置了7000多张表（状态MOVE_ARCH_SUCC）,而CLEAN_ARCH_FAIL和MOVE_ARCH_FAIL的场景都基本上是因为人工干预导致操作失败。

而清理展开之后，一下子就清理了几十套环境的7000多张表。