前几天花了不少时间在元数据审计上。其实这只是一个初步的开始，也算是走正道的开始。在后续中，我推出了多项改进。我计划逐步提高元数据的粒度和深度。通过完善已有的元数据，可以发现很多潜在的问题，然后逐步完善。对于团队中的同学来说，他们不需要花费大量的精力去收集信息，让任务去做，他们需要做的就是确认并修复问题。比如通用元数据部分，对于一个MySQL实例来说，基本包括IP、端口、机房、数据库角色（Master、Slave等）、数据版本、应用信息等。系统层面的元数据，比如hard磁盘、内存和CPU应由专有模块维护。准确的说，以上信息只是笼统的，很难满足业务的实际需求，比如一个MySQL服务器配置，是否启用GTID，版本，角色，socket文件路径，数据文件路径，buffer_pool大小，是否启用binlog，server_id，VIP等信息其实是我们需要清楚的。有了这些信息，我们其实可以对实例的属性有一个基本的了解。整个信息收集看起来是一个非常辛苦的过程。事实上，我们可以让它更高。比如我们收集信息后，通过前端页面对信息进行汇总和查看。例如，我们可以自动完成数据收集和批量完成，而无需手动触发完成。我们可以编写脚本来完成这些任务，也可以收集信息，但是信息管理和协调与单纯的信息收集不是一个层次的。这个地方要做的就是元数据的管理和审计，提前发现更多的问题，逐步完善，让元数据至少可以被引用和依赖。到了这个层次之后，我们其实可以得到一个基本的实例属性列表，但是显然还是有不足之处。我们的MySQL实例基本上是主从复制关系。有些实例可能是测试环境或者数据流的节点，所以可能没有slaves，也没有backups。所以对于MySQL信息的分类，我会做如下分类处理：1、第一个维度是单点实例，即测试环境、数据流节点或者优先级较低的业务。这些服务允许数据丢失，甚至允许重建环境，只要有基本的备份。我们先把这类业务分离出来，后面处理的时候可以绕过这些节点。例如，对于这些节点，可能不需要备份，可能不需要每日备份，根本不需要增量备份或binlog备份。按照这个方案，确认信息后，备份和恢复要等到后面有依据，不然会花很长时间，***发现业务优先级不高，性价比高做事的效率会大大降低。2.第二个维度是数据库的作用。事实上，数据库的角色不能严格划分为Master或Slave。其实还可以有更多的类型，比如单点业务，我们可以归类为SingleDB。如果是中继节点（showmasterstatus或showslavestatus有双重作用），我们可以归类为RelayDB，如果是主库或从库，则为Master，Slave，如果属于MHA或MGR集群environment等，其实这个作用可以更清楚，我们需要对这部分信息做减法，也就是MHA或者MGR的environment。这种信息可以归类为聚类信息。我们可以按照SingleDB、RelayDB、Master、Slave这四个维度统计其他信息。.要实现这个功能，需要增加一些技巧。这里我们需要两个脚本：1）通过IP和端口信息知道实例的角色（Master、Slave、RelayDB、SingleDB等）。2）通过Slave和RelayDB的信息获取Master的信息。通过这些信息，我们可以清晰的实现复制关系图，甚至可以看到一些意想不到的问题。比如下面的IP信息中，数据库的角色是中继节点RelayDB（Master和Slave）。我们可以根据IP的最后两段搜索下面的基本列表。这样的关系，如果自己刻意去维护，很容易搞糊涂，或者意识不到这个级联关系的存在，但是我们把这些数据抽象出来，很快就可以得到这样的关系图，原来是这样的级联关系。这样中继节点124.16的作用和上下游关系就很清楚了。由此看来，是否需要备份124.76的数据就很容易得出结论了。或者你可以基于这样的关系结构构建一个更完整的关系图，你可以清楚地判断是否有任何环境缺少信息。这个阶段，就是发挥数据分析价值的时候了。数据一直都在，就看你怎么处理了。
