这篇文章给大家介绍MySQL中怎么维护主从信息的元数据，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
1.***个维度是单点实例，单点实例是那些测试环境，数据流转节点或者业务优先级不高的业务。这些业务允许数据丢失，甚至允许环境重建，有一个基本的备份即可，这类的业务我们首先剥离出来，后面处理的时候就可以可以绕过这些节点，比如对于这些节点来说，可能不需要备份，可能不需要每天备份，压根不需要增量备份，binlog备份，按照这个规划，做了这些信息确认之后，后期要完成的备份恢复就有据可依，要不费了半天劲，***发现业务优先级不高，做事情的性价比就大打折扣。
2.第二个维度是数据库角色，数据库的角色其实不能严格意义上归类为Master,Slave，其实可以有更多的类型，比如单点业务，我们可以归类为SingleDB,如果是中继节点（show master status或者show slave status持有双重角色），我们可以归类为RelayDB,如果是主库或者是从库即为Master,Slave,如果属于MHA或者MGR的集群环境等，其实这个角色可以更加清晰，对于这部分信息我们需要做减法，即MHA或者MGR的环境，这类信息可以归类为集群信息，我们可以对其他的信息按照SingleDB,RelayDB,Master,Slave这四个维度来统计即可。
要实现这个功能，就有一些技巧需要补充了。
我们在这里需要两个脚本：
1）通过IP和端口信息得知实例的角色（Master,Slave,RelayDB,SingleDB等）
2）通过Slave和RelayDB的信息来得到Master的信息，亮点也就在此，通过这些信息我们可以清晰的达到一个复制关系图，甚至可以看到一些意想不到的问题。
比如下面的IP信息，数据库角色是中继节点RelayDB（既是Master又是Slave）
我们根据IP的后两段内容搜索得到下面的一个基本列表。
这样一个关系，如果自己来刻意维护，其实很容易就会迷茫，或者意识不到这种级联关系的存在，但是我们对这些数据进行抽象，就很快能够得到这样的饿一个关系图，原来是这样的一个级联关系。这样一来124.16这个中继节点的角色和上下游的关系就很清晰了，那么从这个角度来看，我们是否需要对124.76做数据的备份就很容易得出结论了。
关于MySQL中怎么维护主从信息的元数据就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
