数据库运维中的元数据建设

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

很多同学可能在工作中已经在初步实践“元数据管理”了，我们大多数使用的方式就是excel,或者在系统中存放一个文本文件。在管理中也勉强够用，当然这种方式存在一些缺点：

1.excel是个人维护的版本，设计思路就是大一统，为了自己以后能看明白，通常会有大量的备注，但是这种备注别人很难看得懂，如果excel丢失基本就歇菜了。

2.系统中存放一个文本文件统一管理，如果涉及多人同时操作，经常会出现“谁修改了我的配置”的情况。

3.数据的更新不及时，无论excel还是统一的文本文件，我们对这些文件的更新都是延迟的，所以经常会发现这个配置的信息已经不准确了，所以我们从来不会拍胸脯保证数据是100%正确。

4.如果配置变更频率较高，以上的变更方式就很让人抓狂了。

5.无论是通过excel还是文本文件，都存在一个使用的瓶颈，那就是对于几十条，几百条信息我们还可以通过手工方式管理，但是如果数据量在上千以后，会发现管理起来力不从心。

所以对于元数据的管理是一个体系化的工作，这会改变我们已有的一些不好的工作方式，对于元数据的标准化和规范化在达成共识的前提下，我们的工作会方便很多。

在数据库运维方向也是如此，我们明确了蛮荒阶段可能存在的管理混乱之后，需要做的是一个体系化的管理工作。

元数据维度设计

对元数据的设计维度，我们可以参考如下的几个维度，当然也可以根据自己的业务现状进行调整：

其中各个维度的一些解释和小结如下：

对于这些维度中，需要优先完善的是实例维度，实例可理解为IP(域名）+端口的组合方式，这是一种行业具有共识的约定。通过实例维度的建设，不断的完善其他几个维度的信息。

把这些内容做更进一步的提炼，可以总结为如下的脑图：

相信到了这里，大家对于数据库元数据的维度设计有了一个初步的了解。

对于这些元数据，如果完成一个体系化的管理，这是摆在我们面前的另外一个难题，我们不妨换一个思路，假设数据都存储好了，这些数据如何组织起来，我们先来梳理一下元数据的关系。

元数据关系梳理

刚刚我们明确了元数据建设的重要性，元数据设计是分为了多个维度，有主机，实例，集群，数据库等。

如何有效的把几个维度组--合起来呢。我们先来看一个元数据的关系图，假设有一个集群A,它所对应的元数据信息应该是如下的关联关系：

其实在这个关系图中，我们的目标是根据任意一个维度都可以进行信息的前后关联，这样元数据其实不是孤立的，也不是单纯的上下游关系，而是一个完整的流程化管理，即其中的一个环节出现了变化，那么应该需要映射到整个元数据体系中。

我们可以做一个略微复杂的关系图，比如集群信息部分，我们是包含分布式集群和高可用集群的，他们的元数据信息是独立的，又彼此关联，我们把分布式集群和高可用集群的信息组合组合起来。假设分布式集群的每一组节点都具有独立的高可用集群，如果实例3发生了宕机，那么需要联动的是高可用集群2的信息，而对于分布式集群来说却不需要关联改动。

同理我们可以从关系图中找到更多的因果关系，当然这会存在一些局限性，我们在元数据流程管理的部分会细说。