上篇我们把OceanBase装起来、把集群成功拉起来了那这篇就顺势进入第一个正事登录集群把它最基本的家底摸清楚。我见过不少刚接触OceanBase的同学装完集群就急着建库建表结果到了要扩容节点、排查慢查询、甚至只是想确认“集群到底有哪几台机器在跑”的时候整个人是懵的——不知道应该查哪张视图不知道Zone和Server是什么关系更不知道哪个字段代表状态正常。说白了OceanBase是分布式架构数据是拆开放在多台机器上的和多副本绑在一起你不先把集群的结构看明白后面所有运维操作都等于在盲人摸象。这篇文章我就从零开始带你把查看OceanBase集群基本信息这条链路彻底走通。这篇内容适合完全没有分布式数据库基础的同学也适合刚部署完OceanBase、想确认集群状态是否正常的入门选手。我会先从OceanBase的几个核心概念讲起再说登录入口怎么选接着给出最常用的查看命令最后逐字段教你读懂输出结果并附上我实际踩过的坑和排查方法。你不用记太多东西把几个关键视图和字段弄明白就够了。1. 先理清楚您手里的OceanBase集群到底由哪些部分组成1.1 三个绕不开的概念Zone、Server、租户看集群信息之前至少要先把OceanBase的核心架构名词弄清楚否则查出来的结果摆在你面前你也只能看个热闹。OceanBase集群从物理到逻辑可以拆成三层。第一层叫Server本质上就是一台运行了OBServer进程的物理机或者容器。每一台Server上面跑着OceanBase的数据库服务进程所有的数据最终都落在这些Server上。第二层叫Zone你可以把它理解成一个逻辑分组一组Server组成一个Zone。为什么要这么分组主要为了容灾。你在部署的时候通常会约定一个Zone的服务器放在同一机房或者同一机架这样如果整个机房出问题只会影响到一个Zone其他Zone的副本还在数据不会丢、服务不会停。第三层叫租户这个概念对新手来说最容易混淆。OceanBase是一个多租户架构的数据库一个集群里面可以创建多个租户每个租户像是一个独立的“逻辑数据库实例”业务方各自用各自的租户资源相互隔离。而集群的管理员操作都是在系统租户sys里完成的。这层结构你在查集群信息的时候会反复遇到。比如__all_server这张视图查出来的每一行是一台Server__all_zone视图查出来的则是Zone的各种属性。不把这三者的关系理顺后面的命令看起来就是一堆没有意义的数据。1.2 为什么“先看集群”比“先建表”更重要很多从单机数据库转过来的同学习惯是装完数据库、建个库、建几张表往里插几条数据就觉得任务完成了。但在OceanBase这种分布式架构下这个习惯会埋坑。原因很简单单机数据库你只要关心一台机器上的进程在不在、端口通不通但OceanBase的一个查询可能同时命中多台Server上的数据任何一台Server状态异常、网络分区、合并卡住都会直接影响业务SQL。所以我自己在实际运维中的顺序永远是先确认集群整体状态再看租户资源最后才轮到建表写数据。这也正是官方文档里日常巡检的标准顺序。查看集群基本信息本质上是在做一次最基础的健康检查——确认有多少台Server在线、有几个Zone是正常的、合并状态有没有报错。这些东西都正常后面才有继续操作的意义。如果集群本身有一个Zone挂了你在这种情况下建表或者做数据导入轻则没有副本可用重则丢数据风险非常大。2. 查看前必须搞定的登录入口和用户权限2.1 登录sys租户这是唯一的集群管理入口要查看集群基本信息的表你首先要登录到OceanBase的sys租户。sys租户是OceanBase系统自带的、用于管理整个集群的租户类似于单机数据库里的root用户权限。在sys租户下你可以看到集群全局的视图比如所有Server、所有Zone、所有资源池。如果你登录的是普通业务租户那你看不到集群层面的信息看到的只是当前租户自己的数据这个是新手最容易搞混的地方。需要注意sys租户默认的root用户密码是你在部署OceanBase时设置的。如果你是用obdOceanBase Deployer安装的部署过程中会让你配置root用户密码千万不要留空。这里有个我实际踩过的坑很多人图省事部署时密码设置得太简单比如纯数字“123456”结果后面为了安全要改成复杂密码还得专门去查修改密码的文档反而多花了时间。2.2 用obclient连接集群的具体命令OceanBase官方推荐的命令行客户端是obclient。它的用法和MySQL的mysql客户端非常像但因为底层有OceanBase特有的协议和命令所以建议直接用obclient不要用mysql客户端去连否则部分集群运维命令会不支持。最基本的登录命令是这样的obclient -h127.0.0.1 -P2881 -urootsys -p -A -c我来逐项解释一下这里的参数因为这串命令以后你每天都要用到。-h指定OBServer的IP地址。如果你是在部署OceanBase的同一台机器上执行写127.0.0.1即可如果要远程连接则填对应的IP。-P指定端口。OceanBase默认的SQL服务端口是2881。注意这里不是RPC端口2882是SQL协议端口2881。-u指定用户名。rootsys表示使用root用户登录sys租户。注意用户名里有个符号这是OceanBase特有的格式格式是“用户名租户名”。-p提示输入密码。-A这个参数很关键表示连接时不开全表缓存。如果你不写它obclient在启动时会尝试读取所有库表信息在集群表比较多的时候登录会变得特别慢甚至卡住。我建议你每次都加上。-c表示在客户端执行命令时不忽略注释。这个参数对于执行带注释的脚本比较有用日常查看集群信息时写不写都行但我习惯加上避免有些命令显示异常。连接成功后命令行会进入obclient提示符这时你就可以开始执行查看集群信息的SQL语句了。2.3 不想敲命令用obd也能看集群状态如果你觉得用SQL视图查集群信息还不太熟练还有一个简单粗暴的办法就是用obd命令直接在操作系统层面查看集群状态。obd是OceanBase部署工具你在安装集群的时候就用过它它也有查看状态的功能。obd cluster list这个命令会列出当前机器上通过obd部署的所有集群名。拿到集群名后继续执行obd cluster display 集群名执行完之后你会看到类似下面的输出OceanBase-CE-4.2.0 --------------------------------------------- | Cluster Info | -------------------------------------------- | id | zone | status | -------------------------------------------- | 1 | zone1 | ACTIVE | | 1 | zone2 | ACTIVE | --------------------------------------------这个命令适合快速确认集群各Zone的状态但它显示的信息相对粗略。如果你要定位具体是哪个Server有问题、某个资源池的分配情况还是要回到SQL视图去查。3. 核心实操三步查看集群基本信息3.1 第一步确认集群拓扑和核心表状态登录obclient之后第一条建议执行的SQL是查看集群的核心表。所谓核心表是指OceanBase集群内部用于记录元数据、管理信息的关键系统表。如果这些表有问题集群基本上就属于不可用状态了。命令如下SELECT * FROM oceanbase.__all_core_table;正常情况下这个查询会立刻返回一行或多行记录显示集群中已经创建的核心表信息。如果这个查询卡住或者报错说明集群内部出现了比较严重的问题这时候你先别继续往下查了而是要先确认OBServer进程是否正常运行。这里稍微解释一下为什么是oceanbase这个库。在OceanBase中system租户下面有一个名为oceanbase的数据库它存放了集群所有的内部系统视图和字典表。你在学习过程中可能会看到sys库、oceanbase库其中oceanbase库才是存系统表的地方。记住这个库名后面几乎每一次查看集群信息都要以它开头。3.2 第二步查看Zone信息第二条命令是查看Zone的信息。我先给命令再解释字段SELECT * FROM oceanbase.__all_zone;返回结果通常包含多行每一行代表某个Zone的某个属性。常见的属性名有region、idc、status等。比如某一行可能是-------------------------------- | zone | name | value | info | -------------------------------- | zone1 | region | hz | NULL | | zone1 | status | ACTIVE | NULL | | zone2 | region | bj | NULL | | zone2 | status | ACTIVE | NULL | --------------------------------看到这个结果你应该能自己解读了集群有两个Zonezone1和zone2一个在杭州一个在北京两个Zone的状态都是ACTIVE。ACTIVE表示这个Zone是正常的、可以对外提供服务的。如果某个Zone的状态不是ACTIVE而是INACTIVE或者DELETING那就要引起重视说明这个Zone可能存在故障或者正在被下线。还有一个很常用的Zone维度信息是合并状态。在OceanBase中数据会周期性进行合并major compaction把内存中的增量数据和磁盘中的基线数据合并到一起。合并是否完成、是否有报错直接影响读写性能和数据一致性。查看合并状态的命令是SELECT zone, name, value FROM oceanbase.__all_zone WHERE name IN (merge_status, is_merge_error);正常状态下merge_status的值为IDLE表示没有正在进行的合并任务is_merge_error的值为FALSE表示最近没有合并错误。如果你发现merge_status长期处于MERGING状态或者is_merge_error变成了TRUE那就要进一步排查合并卡住或失败的原因了这在生产环境属于比较重要的问题。3.3 第三步查看Server列表和状态Zone看完了接下来要看具体有哪些Server在提供数据库服务这个信息才是“集群有几台机器”的直接答案。执行SELECT * FROM oceanbase.__all_server;这条命令返回的字段比较多核心的几列如下svr_ipServer的IP地址。svr_portServer的RPC端口默认是2882。zone这个Server归属哪个Zone。statusServer的状态常见的有ACTIVE、INACTIVE、DELETING。start_service_time这个Server最近一次启动服务的时间。stop_timeServer的停止时间。如果这里不是NULL说明这台Server曾经被主动停止过服务。正常情况下的理想状态是你部署了几台Server这里就出现几行记录并且所有记录的status都是ACTIVEstop_time都是NULL。如果某个Server的status变成了INACTIVE就意味着它已经和集群失联了这时候你再看看stop_time如果这个字段有值大概率是之前有人善意地把这台机器下线了但忘了重新拉起。除了看数量这里我还会建议你顺手关注一下start_service_time。如果集群里某一台Server的启动时间明显比其他机器晚说明这台机器中途发生过重启虽然现在状态是ACTIVE但你需要多关注一下它的稳定性。3.4 补充操作看资源池和租户概览查完Server集群的基本物理结构已经清楚了。但一个集群能不能被业务正常使用还要看资源池和租户的分配情况。资源池是OceanBase里分配资源的重要概念它连接了Server和租户。创建租户时你必须先创建一个资源池然后指定这个资源池包含哪些Zone、每份资源的规格。执行SELECT * FROM oceanbase.__all_resource_pool;这个查询会显示所有资源池的名称、ID、绑定的Zone列表等信息。如果你发现某个资源池绑定的Zone列表和实际Zone数量不一致比如集群有三个Zone但资源池只包含了两个那说明这个资源池的容灾能力是不完整的一旦没包含的那个Zone出故障资源池对应的租户就只剩一个副本了数据风险很高。租户信息也很重要执行SELECT * FROM oceanbase.__all_tenant;这条SQL会列出当前集群下的所有租户包括sys系统租户以及你手动创建的业务租户。每个租户有自己独立的ID、名称、状态等信息。对于入门阶段你只要确认这里面有你预期创建的租户、状态是NORMAL就说明租户本身是健康的。4. 看懂输出结果每个字段背后到底说明什么问题4.1 别急着背命令先学会看“状态族”字段很多同学查完__all_server看到一堆字段就晕了其实没必要全部记住。OceanBase视图里的字段虽然多但大致分成三类标识类、状态类和配置类。标识类字段用于告诉你这一行记录代表的是哪个对象比如IP、端口、Zone名、租户名配置类字段用于记录这个对象的属性配置比如CPU、内存大小、某个参数值而状态类字段是这个对象当前是不是正常工作的直接体现比如status、stop_time、merge_status、is_merge_error。我建议你在入门阶段优先关注状态类字段因为它们决定了集群是否健康。看到一个状态字段第一时间去查它的取值含义。这里有一个通用原则绝大多数状态字段出现ACTIVE、NORMAL、IDLE、FALSE这类“正向”的关键词都是正常的出现INACTIVE、ERROR、TRUE、FAILED这类“负向”的关键词都需要重点关注。这样你就不需要背所有字段了看到新字段先判断它是三类中的哪一类再去看它的取值是正还是负这个习惯在查看任何新系统时都很好用。4.2 一张表看清常用视图的关键字段为了让你平时排查更方便我把上面提到的几个视图和它们最关键、最需要关心的字段整理成了一张速查表。视图主要作用最需要关注的字段oceanbase.__all_core_table确认集群核心系统表状态能否正常返回结果oceanbase.__all_zone查看Zone级配置与状态zone、name、value尤其看statusoceanbase.__all_server查看每台Server的状态svr_ip、zone、status、stop_timeoceanbase.__all_resource_pool查看资源池与Zone绑定关系resource_pool_name、zone_listoceanbase.__all_tenant查看租户列表与状态tenant_name、statusoceanbase.__all_zone条件查询查看合并状态与错误标记merge_status、is_merge_error这张表你可以先截个图或者存个书签平时做巡检的时候就照着这六条SQL去看。全部执行一遍正常情况下不到一分钟就能看完但能换来对整个集群非常准确的把握。我后面在问题排查部分就是基于这张表来判断的。4.3 什么样算“正常”什么样算“报警”光会执行SQL还不够你还得知道执行完以后什么结果代表正常、什么结果代表异常。我根据自己的实践经验总结了一些可以直接拿来用的判断标准。正常状态下的几个表现__all_zone中的status全是ACTIVE__all_server中的所有Server都是ACTIVE且stop_time为NULL__all_tenant中的租户状态是NORMALmerge_status的值为IDLEis_merge_error是FALSE。看到这些你就可以放心地继续建库建表了。需要引起警惕的状态包括某个Zone的status不是ACTIVE说明这个Zone可能在做扩缩容或者已经故障数据副本可能不完整某个Server的status是INACTIVE说明这台机器和集群的心跳已经断了需要立刻检查对应物理机的进程和网络is_merge_error是TRUE说明合并出错了这种问题一般伴随写入性能下降或查询异常。另外还有一个小细节如果你在__all_tenant里看到有租户的状态是CREATING但很久都没变成NORMAL那很可能是资源池分配有问题或者对应Zone状态异常导致创建租户卡住。5. 常见问题与排查技巧实录5.1 命令报错最常见的五个原因我见过太多初学者在查看集群信息时遇到报错下面几个原因是最常见的其中前三个几乎覆盖了90%的情况。第一个最普遍的问题是登录时报Access denied。这个原因基本都是用户名格式写错了或者密码不对。记住查看集群信息必须用rootsys登录如果你漏掉了sys或者密码大小写不对都会直接拒绝连接。第二个问题是连接超时。通常是-h指定的IP和端口不对或者没有加-A参数导致连接时加载太慢。如果你能确认IP端口没问题优先检查一下2881端口有没有被防火墙拦截。第三个问题是登录进去了但查询时报Table doesnt exist或者视图不存在。这个大概率是版本原因不同版本的OceanBase内部视图名称或字段会略有调整。如果你用的是4.x版本有些视图可能从__all_系列调整成了新的数据字典视图比如DBA_OB_*这时候可以参考对应版本的系统视图文档来确认名称。第四个问题是执行SQL时卡住不返回。这种情况常见于集群状态不正常比如有Server心跳丢失导致内部元数据读取等待。遇到这种问题先退出客户端用obd cluster display快速看一眼集群健康状态。第五个问题比较隐蔽就是明明集群正常但查出来的数据和预期对不上比如Server数量少了。这个多半是因为你登录的不是sys租户普通业务租户的可见范围有限看不到全局的Server列表。5.2 一个通用排查思路三步定位法如果执行查看命令时遇到问题别慌记住我下面说的这个三步定位法。第一先确认进程层是否正常。到目标机器上执行ps -ef | grep observer看看OBServer进程是否还活着如果没有进程说明数据库服务已经停了这时候查SQL必然失败。第二确认网络层是否通畅。从你执行命令的机器上执行telnet 目标IP 2881看端口能不能通。很多时候服务本身没问题但网络策略拦了表现起来也是连接失败。第三确认系统视图层是否可读。用obclient登录sys租户执行最简单的SELECT 1;如果这个能成功而查视图失败那问题基本就是视图名或字段名写错了回到上一节说的版本兼容性问题去排查。5.3 零基础最值得养成的三个习惯最后聊几个我觉得特别有帮助的习惯这些算不上什么高级技巧但真能让你的入门之路顺畅很多。第一个习惯是每次都加上-A参数登录。我见过很多人因为没加这个参数明明集群有几百张表登录时卡了十几秒甚至更久然后就开始怀疑集群有问题。第二个习惯是定期把上面那张速查表里的SQL依次执行一遍并保存一份输出结果。比如每周一早上花五分钟跑一次顺便存个日志。这样一旦集群出问题你可以翻出之前的正常输出做对比很容易就看出哪台Server、哪个Zone是最近才开始异常的。第三个习惯是写一个简单的shell脚本把这几个查询命令封装起来平时一条命令就能完成整套集群信息查看。比如新建一个check_oceanbase.sh内容大概是这样#!/bin/bash OB_USERrootsys OB_HOST127.0.0.1 OB_PORT2881 obclient -h${OB_HOST} -P${OB_PORT} -u${OB_USER} -p -A -c SELECT Zone状态 AS info, zone, name, value FROM oceanbase.__all_zone WHERE namestatus; SELECT Server状态 AS info, svr_ip, zone, status, stop_time FROM oceanbase.__all_server; SELECT 租户状态 AS info, tenant_id, tenant_name, status FROM oceanbase.__all_tenant; 执行的时候输入一次密码所有最关键的集群信息就都出来了。这个脚本我在测试环境一直用非常省事。等你以后把用户密码通过环境变量管理起来这基本上就是一个很轻量的巡检工具了。我自己在刚开始上手OceanBase的时候也曾经对着__all_zone和__all_server里的几十个字段发懵后来慢慢发现真正日常要盯的就那么几个状态位。把这条查看集群信息的链路走通之后再去看租户创建、资源扩容这些操作你会觉得心里特别有底。到了下一篇我建议你可以试着用同样的思路去创建第一个业务租户然后再进去建表插数据那时候你会发现入门OceanBase这件事真的没有想象中那么难。