Oceanbase的元数据藏得太深了

白鳝的洞穴 2022-03-08

2951

前两天写了两天杂谈，周一上班就该回归技术了，实际上周末在家我也一直在看OB的文档。相对于其他国产数据库来说，OB的文档还算是比较全的，不过这也仅仅是相对而已，对于要做一个OB的智能化运维工具来说还是十分不足的。幸好和OB的团队的交流还十分畅通，并且在开源社区上也可以提出一些需求。我想了解的内容应该会逐渐搞清楚的。

周末一直在梳理OCEANBASE的一些指标，所以对OB的一些细节做了比较认真的分析。通过这次分析，我们团队重新认识了一遍OB。以前我们仅仅是做OB和其他数据库之间的对比测试，重点还是在高可用，压测等应用层面为主的环节。这回需要构建OB的运维模型，因此关注的更为细致了。

通过这段时间恶补知识，我们的OB的理解也更深入了。通过学习发现OB的整体架构还是十分不错的。不过OB这样的分布式数据库，其逻辑结构，物理结构还是十分复杂的。OB CLUSTER、数据库、可用域、OBSERVER、资源管理、租户等等，这些概念有的是逻辑的有的是物理的，几条线穿插在一起相当复杂。

从物理结构这条线，一个OB CLUSTER可能会有多个物理节点组成，每个节点可以是一台物理机，也可以是虚拟机。每个Node1上可以运行一个或者多个OBSERVER。一组OBSERVER可以属于一个可用域（zone）,zone的目的是为了确保高可用，一个数据的多个分片副本，存储到不同的zone里，任何一个zone出问题，都不会丢失数据。数据库的用户通过obproxy可以连接到任何一个OBSERVER上来执行SQL语句，obproxy会自动做负载均衡。

似乎这个架构还是十分清晰的，不过如果我们再深入一点，把OB的租户概念引入进来，那就复杂多了。租户是一个逻辑的概念，在一个OB CLUSTER上我们可以创建多个租户，对于用户来说，每个租户好像是一个独立的OB CLUSTER集群一样。

实际上我们的应用并不是直接连接到OB CLUSTER上的，而是连接到某个租户上，目前OB的租户有MYSQL租户和Oracle租户两种，通过连接租户的不同，obproxy会自动转发连接。OB CLUSTER也会根据用户名的格式user@tenant#database来确定连接的租户。这种租户有点类似于ORACLE的PDB，不过差别还是很大的。Oracle的PDB在物理结构上有自己完全独立的数据文件，而OB的租户是完全逻辑的概念。通过资源单元，OB可以限制每个租户可以使用的CPU,内存，IO存储等资源，而实际上可能多个租户的资源都是共享的。所有租户的计算能力都是observer提供的。OB提供两种兼容性的租户，其逻辑架构又有所不同，也让整体架构变得更为复杂。在MYSQL租户中，有database的概念，而Oracle租户中只有schema。Mysql租户是完全和Mysql兼容的，Oracle租户知识貌似Oracle，实际上和Oracle的客户端时不兼容的。在具体实现上，是在一个统一的架构上做了一层Oracle兼容性外壳。

OB的资源管理做的十分严格，分配给每个租户的资源被严格的控制，一旦超出，则会产生报错。这种严格控制可以确保租户之间的强隔离，这对于一个企业构建一个广泛共享的OB集群提供了很好的保障。不过，这对于OB的运维来说提出了更高的要求，确保多租户的资源得到有效的利用和确保每个租户的资源在高峰期都不会出现不足，对于系统运维来说至关重要。

通过上面的简单介绍，我们可以看出OB是十分复杂的。因为其复杂，管理起来也就不那么简单了。我们的D-SMART要对接OB数据库，首先需要将其配置信息CIB和主要的监控指标都找出来。我们在分析的过程中发现了一个问题，那就是无论从OB的官方文档还是在数据库上，总是发现缺少一些能够找到OB集群的一些关键信息的视图或者系统表。

在OB的安装指南里，有一条查看系统资源的SQL语句，里面查找了一张系统视图__all_virtual_server_stat。不过我们无论是使用show tables命令还是在__all_table里，都查不到这些表的信息。

这些表都定义在什么地方呢？

在OB中除了oceanbase外，还有两个默认数据库，information_schema和Mysql。Information_schema是mysql中访问数据库元数据的接口，并不是实际的物理数据库。

通过show tables命令看到面也有一个TABLES系统视图，按理说Mysql的show tables命令就是通过这个接口来查找信息的，我们来看看这个表里面有什么信息。

这些__all_virtual_*的系统表，所属的数据库是oceanbase，在oceanbase数据库里找不到任何踪迹，在这里居然都找到了，OB把这些信息藏得够深的。

找到了这些表，我们就补齐了了解OB整个架构的所有信息了。这样我们就可以看到每个OBSERVER的磁盘使用情况了。在下面的SQL中，我们也可以看到obproxy的状态，了解每个observer的工作状态。

通过对OB的分析，我们既看到了国产数据库的巨大进步，也看到了其不足的地方。国产数据库除了提升自身的技术水平之外，知识生态，技术生态，服务生态的建设也十分重要。如果不能让大量的用户、第三方服务团队很好的了解国产数据库，那么国产数据库的应用还是会遇到巨大的阻力。来自未知的恐惧远甚于已知的害怕。

oceanbase

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oceanbase的元数据藏得太深了

评论