数据生命周期管理的思考

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

今天在思考数据生命周期管理的时候，理清了一些思路。

作为DBA，其实需要从更高的一个角度来看待你所管理的数据。

打个比方，如果我知道我管理的1000个数据库每天发生了多少张表的变更，哪些是人工触发的，哪些是程序触发的，如果我们知道，那么我们处理问题的时候会更加主动，而绝大多数情况下，其实我们是不知道的，或者说我们觉得不需要关注这些。

我们来细化一下，对于表的DML操作，应该是程序端能够处理的，对于这部分的数据，其实我们可以通过快照的方式来处理，比如总共有1万张表，那么我们可以做周期性的抽取，通过细粒度的数据抽取，我们可以知道某个表在一段时间内的数据变化情况，是否存在碎片等，当然这个频率不宜过高，一般一天一次到两次即可。

对于DDL的操作，其实比较抽象，有CREATE,ALTER,DROP, （不包含TRUNCATE)，简单来说，也是周期性抽取，频率可能会更高一些，但是数据量要远比DML的小得多。假设10000张表100天发生了20次变更，那么总的抽取记录数就应该是10020，而不是10000*100=100万，所以相比来说，这是一种因需而动的处理方式，

这个DDL的场景怎么落地，和数据生命周期管理如何关联起来，我们举个例子。比如表test有10个字段，在一个月以后，字段数是20个，那么可以通过两个维度，第一个是时间维度，从10个字段到20个字段，在这段时间范围内是如何变化的。比如我们可以根据数据的变化轨迹定位到10个字段到19个字段的过程，第二个维度，从字段名触发，某个字段在一段时间里是否发生了变化，比如类型从varchar(30)变为varchar(50)

我们可以通过抽取的建表语句来进行比对。

比如我们根据DDL变化做了两次抽取，可以理解是两个快照，那么通过对比两个快照就可以轻松的得到我们需要的信息，通过时间维度或者字段信息。

DDL里面对于DROP的操作是一个敏感而且模糊的处理，我们可以通过标识DDL类型来进行周期维护，如何确定表被删除了，一定是通过已有的参考依旧才能够分辨出来，MySQL不会主动通过数据字典来告知你。

当然这个列表也可以通过mysqldump的备份来补充，比如我们做mysqldump备份，只备份表结构，其实就几秒钟的事情，我们可以通过dump文件轻松得到一个库的表信息列表。

可以使用如下的脚本命令：

grep -E "^CREATE TABLE|^CREATE DATABASE" devopsdb.sql |sed 's/\/\*\!32312 IF NOT EXISTS\*\///g'|sed 's/IF NOT EXISTS//g'|sed 's/CREATE//g'|awk '{print $1" "$2}'|sed 's/TABLE/--/g'

这个脚本会输出数据库的表列表，格式类似这样的形式：

DATABASE `test`

-- `dept`

-- `emp`

-- `mysql_info`

-- `t`

-- `t1`

-- `t2`

-- `test`

-- `test_data`

-- `tmp`

DATABASE `test2`

-- `test`