OceanBase 装完之后很多人第一个念头就是赶紧建表、导数据但我要劝你先冷静一下比起急着写 DDL你更应该先学会查看集群基本信息。这就跟买车一样仪表盘还没看懂就踩油门上路迟早要出事。这篇是“零基础 OceanBase 数据库入门”系列的第二篇主题就一个——装完 OceanBase 之后怎么用几条 SQL 和命令把集群里的节点、Zone、租户、资源分布一次摸清楚。这篇文章适合刚装完 OceanBase不管是单机版还是三节点还搞不清该看哪个视图的人也适合那些正准备做数据库课程设计、写实验报告、或者准备 kca 考试的同学。你可以把它当成一份速查手册命令直接抄字段含义直接看踩坑点也帮你提前标好了。1. 看集群之前先弄懂 OceanBase 里“集群”到底指什么1.1 集群、Zone、Server、租户的逻辑关系很多人一上来就敲 SQL结果连查询结果都看不懂问题出在概念没理清。OceanBase 的集群体系可以拆成四层集群Cluster、Zone、Server也就是 observer 进程、租户Tenant。集群是整个数据库实例的总称对外表现为一个完整的数据库一个集群里可以有多个 ZoneZone 是逻辑上的容灾单元你可以把它理解成“机房里的一个区域”或者“机架上的一个分组”。每个 Zone 下面分布着若干台机器每台机器上跑着一个 observer 进程这就是 Server。最后是租户OceanBase 天生是多租户架构业务数据都放在租户里租户又分为 MySQL 模式和 Oracle 模式。这里有个新手最容易绕晕的点单机版也会有多个 Zone。比如你用 OBD 在一台服务器上部署一个“1-1-1”的架构实际上是在一台物理机上模拟了三个逻辑 Zone每个 Zone 里一个 observer。这种部署在容灾上没有任何意义机器挂了全挂但它能完整模拟生产环境的逻辑结构用来学习、做实验非常合适。1.2 为什么查集群信息必须登录 sys 租户查集群信息核心入口是 sys 租户。sys 是 OceanBase 内置的管理员租户所有集群级别的元数据都保存在 sys 租户内部哪些节点在线、哪些 Zone 是活着的、资源池怎么分配、副本怎么分布全部得在 sys 租户下才能看到。连接方式是rootsys意思就是 sys 租户下的 root 用户。普通业务租户登录后只能看到自己租户内部的数据字典和性能视图查不到集群全局拓扑。打个比方业务租户像小区里的住户能看到自己家里有几间房sys 租户像物业能看到整个小区有几栋楼、每栋楼住了多少人、水电管网怎么走。1.3 版本差异4.x 请用 DBA_OB_ 开头的视图查集群信息网上能搜到很多旧教程动不动就让你select * from __all_server;。这类以__all_开头的表是 OceanBase 3.x 及更早版本的内部表。注意是内部表不是对外承诺的稳定接口字段随时可能调整。从 4.x 开始官方推荐使用oceanbase库下DBA_OB_开头的系统视图来查看集群信息。这套视图命名规整、字段清晰是 4.x 之后对外承诺的稳定查询入口。所以你现在搜教程只要看到__all_开头的写法建议先留个心眼确认一下那篇教程对应的版本。这篇博文所有示例都基于 4.x 版本查询时统一用DBA_OB_视图。2. 别急着敲 SQL先用几条命令确认 observer 活着没2.1 进程层面确认 observer数据库是不是活着第一层是操作系统层面。登录到部署 observer 的服务器上执行ps -ef | grep observer正常情况下你会在输出里看到类似这样的进程admin 12345 1 0 10:00 ? 00:00:00 /home/admin/oceanbase/bin/observer -z zone1 -P 2881 -p 2882重点看两件事PID 存在且没有被标记为僵尸进程启动参数里的-P和-p跟你的预期一致。其中-P 2881是 SQL 对外服务端口-p 2882是 observer 内部 RPC 通信端口。如果 ps 看不到 observer先别急着查数据库问题在进程就没起来。这时候去翻日志后面会讲。2.2 端口和日志进程活着不代表端口一定能连建议再确认一下端口监听状态netstat -tlnp | grep -E 2881|2882必须看到 2881 和 2882 处于 LISTEN 状态。2881 是客户端连库的 SQL 端口2882 是集群内部节点之间通信的端口。如果只监听了 2882说明进程可能还在启动阶段多等一会儿再看。日志是排查一切问题的终点。用 OBD 默认方式部署的话observer 日志一般在安装目录下的log文件夹里常见路径是~/oceanbase/log/observer.log。启动阶段看日志用这个命令tail -n 200 ~/oceanbase/log/observer.log判断标准很简单日志还在持续滚动输出说明进程在干活日志停在某个 ERROR 上不再动了说明启动失败把最后几十行报错看完基本就能定位到原因内存不足、端口被占用、目录权限不对是最常见的三类。2.3 向数据库发出第一条连接命令进程和端口都正常接下来用 obclient 连进去。连接命令obclient -h127.0.0.1 -P2881 -urootsys -p -A -c逐个参数说-h是 observer 所在机器地址本机就填 127.0.0.1-P是 SQL 端口 2881-u后面是用户名加租户名的组合rootsys表示 sys 租户的 root-p表示需要密码回车后会交互式输入不建议直接写在命令行里避免被 shell 历史记录泄密。这里有两个容易被忽略的小参数。-A是关闭自动补全连接时如果元数据较多不带-A可能会在执行补全的瞬间卡一下-c是让客户端不要截断长字符串查视图时有些字段值很长不截断才能看到完整内容。如果你机器上没装 obclient也可以用 mysql 客户端临时连接但要注意两点一是要加--default-authmysql_native_password参数否则新版 mysql 客户端会因为认证插件不兼容报错二是 obclient 对 OceanBase 的兼容性最好长期使用建议还是把 obclient 装上。另外注意一个端口陷阱2881 是直连 observer 的端口如果你部署了 OBProxy从 OBProxy 访问数据库的默认端口是 2883。用 2883 连接时用户名写法不变但本质是走了中间件路由跟你直连 observer 看到的元数据是一样的。排查连接问题时先搞清楚自己连的是哪个入口。3. 核心实操几条 SQL 看清集群全家桶3.1 先看节点状态oceanbase.DBA_OB_SERVERS连上 sys 租户后第一件事就是看集群里有哪些节点、各自状态如何。执行SELECT SVR_IP, SVR_PORT, ZONE, SQL_PORT, WITH_ROOTSERVER, STATUS, START_SERVICE_TIME, BUILD_VERSION FROM oceanbase.DBA_OB_SERVERS;这条 SQL 是查看 OceanBase 集群基本信息最核心的一条字段含义逐个拆解SVR_IP和SVR_PORT这台 observer 的 IP 和内部 RPC 端口SVR_PORT一般显示 2882ZONE该节点属于哪个 ZoneSQL_PORT客户端连这个节点的 SQL 端口一般显示 2881WITH_ROOTSERVER标记该节点是否承载 RootService 相关服务。在 4.x 中 RootService 的职责已经打散到多节点这个字段参考意义大于实际意义STATUS节点状态ACTIVE表示正常对外服务INACTIVE表示节点心跳异常或不可用START_SERVICE_TIME节点开始对外提供服务的时间如果是空值说明这个节点虽然进程起来了但还没正式加入集群服务BUILD_VERSIONobserver 的编译版本号确认版本时直接看这列比到处问人靠谱。正常的查询结果每台节点对应一行状态是 ACTIVESTART_SERVICE_TIME 有值。如果这个查询能出来说明集群控制面是通的。3.2 再看 Zone 和地域信息oceanbase.DBA_OB_ZONES节点看完再看 Zone 维度。执行SELECT ZONE, STATUS, REGION, IDC, TYPE FROM oceanbase.DBA_OB_ZONES;ZONE是 Zone 名称STATUS表示 Zone 是否可用ACTIVE/INACTIVEREGION和IDC表示这个 Zone 在哪个地域、哪个机房多 IDC 部署时重点关注这两列TYPE用来标识 Zone 的读写类型常规部署一般是读写。这里要理解 Zone 在 OceanBase 里的定位它是容灾的基本单元生产环境通常建议至少 3 个 Zone分布在不同的物理机架甚至不同机房这样任何一个 Zone 整体宕机数据仍然有副本在其他 Zone 提供服务。单机部署的同学看到三个 Zone 别慌这是正常的逻辑结构不代表你真有三套物理机器。学习阶段完全够用但心里要明白单机多 Zone 没有物理容灾效果。3.3 租户、资源池、资源单元一把梭四张表联合查询集群拓扑看完接下来就是租户和资源。OceanBase 的资源管理是一条链租户申请资源资源从资源池里划资源池最终落实到具体节点上的资源单元。先看有哪些租户SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, STATUS FROM oceanbase.DBA_OB_TENANTS;TENANT_ID是租户 IDTENANT_NAME是租户名你看到sys租户的 ID 一般是 1TENANT_TYPE表示租户类型SYS是系统租户业务租户通常是USER类型PRIMARY_ZONE表示租户主副本优先分布在哪个 ZoneLOCALITY描述副本分布规则比如Fzone1,Fzone2,Fzone3表示三个 Zone 里各放一个全功能副本。再看资源池SELECT RESOURCE_POOL_ID, NAME, TENANT_ID, UNIT_COUNT, UNIT_CONFIG_NAME, ZONE_LIST FROM oceanbase.DBA_OB_RESOURCE_POOLS;重点看UNIT_COUNT这个资源池在多少个节点上有单元和ZONE_LIST覆盖哪些 Zone。继续下钻到资源单元SELECT UNIT_ID, RESOURCE_POOL_ID, TENANT_ID, SVR_IP, ZONE, MAX_CPU, MEMORY_SIZE, STATUS FROM oceanbase.DBA_OB_UNITS;MAX_CPU是 CPU 上限MEMORY_SIZE是内存大小单位是字节。最后看一眼资源规格定义SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE FROM oceanbase.DBA_OB_UNIT_CONFIGS;单独看每张表容易晕把它们联合起来查一次整个资源分配关系就清楚了SELECT t.TENANT_NAME AS tenant_name, r.NAME AS pool_name, r.ZONE_LIST AS zones, u.SVR_IP AS server_ip, u.MAX_CPU AS max_cpu, ROUND(u.MEMORY_SIZE / 1024 / 1024 / 1024, 2) AS mem_gb FROM oceanbase.DBA_OB_TENANTS t JOIN oceanbase.DBA_OB_RESOURCE_POOLS r ON t.TENANT_ID r.TENANT_ID JOIN oceanbase.DBA_OB_UNITS u ON r.RESOURCE_POOL_ID u.RESOURCE_POOL_ID;这条 SQL 执行完你能看到每个租户的资源池落在哪几个 Zone、具体哪个节点的 IP、分到了多少 CPU 和内存。后面做租户扩容、缩容、迁移副本时这个查询结果就是你做判断的底图。3.4 顺带确认版本和集群 ID排查问题或者跟别人对接时版本和集群 ID 经常要确认。版本信息特别简单SELECT version();集群 ID 用参数查询SHOW PARAMETERS LIKE cluster_id;执行后会列出cluster_id这个参数以及对应的值。注意SHOW PARAMETERS的结果里一行的VALUE列才是真正的集群 ID。集群 ID 在多集群场景下很重要比如做数据迁移、监控上报、多集群管理时都是靠集群 ID 区分不同集群的。如果你习惯用 DBeaver 这类图形化工具连接 OceanBase用户名同样是rootsys这种“用户租户”的写法端口同样区分 2881直连 observer和 2883走 OBProxy。用工具看数据确实直观但命令行这几条 SQL 还是要练熟因为生产环境很多时候你没有图形工具可用。4. 实操中常见报错与排查方法4.1 连不上ERROR 2003 / 10061现象是提示Cant connect to MySQL server on 127.0.0.1 (10061)。这说明端口根本没通。排查顺序固定下来先ps -ef | grep observer看进程再netstat -tlnp | grep -E 2881|2882看端口然后检查防火墙是否放行了对应端口。如果是本地学习环境最简单的方式是先把 firewalld 停掉再测生产环境要放行端口规则不要简单粗暴关防火墙。还有一种情况是用 OBProxy 连接失败但直连 observer 成功问题定位在 OBProxy 本身检查 OBProxy 进程和它的 2883 端口。4.2 权限报错ERROR 1045 / ERROR 4012ERROR 1045 Access denied for user root...说明用户名或密码不对。ERROR 4012也是 OceanBase 常见的认证失败错误码。先检查用户名写法-urootsys中间不要有空格租户名不能写错。再看密码OBD 部署时如果没有显式设置密码root 用户密码一般是部署配置里指定的或者可能为空。空密码的话执行连接命令后直接按回车就行。如果你忘了密码最快的路子是去翻 OBD 部署时的配置或记录而不是在数据库里瞎猜。生产环境密码通常会上到密钥管理或配置中心去那里找。4.3 查询报错表不存在 / unknown database连接后直接执行SELECT * FROM DBA_OB_SERVERS;报表不存在原因是没加库名前缀。这些视图都在oceanbase库下两种写法都对SELECT * FROM oceanbase.DBA_OB_SERVERS;或者先执行use oceanbase;再查。建议第一种写法命令一条条都能独立执行不会被当前库状态影响。4.4 报 -4000 / something wrong 等内部错误这种报错信息比较模糊通常是 observer 内部没有准备好。比如节点刚启动还在初始化阶段RootService 还没选主完成这时候查集群视图就可能报内部错误。处理办法是等几十秒再试同时看 observer.log 有没有 ERROR 级别的日志刷出来。另一类情况是版本不匹配你用 3.x 时期的内部表名去查 4.x 集群或者反过来都会出现奇怪的报错。记住前面说的4.x 统一用DBA_OB_视图能避开绝大多数兼容性问题。现象常见原因排查方向10061/2003 连接失败进程没起、端口没监听、防火墙拦截ps、netstat、防火墙规则1045/4012 认证失败密码错误、用户名租户格式不对核对 rootsys 写法、重置密码表不存在没加 oceanbase 库名前缀用 oceanbase.DBA_OB_xxx 全名查询-4000 内部错误节点未就绪、版本不匹配看 observer.log、等待就绪、核对版本5. 查看集群信息不只是为了看一眼5.1 结合 OBD 命令双通道查看如果你是用 OBD 部署的 OceanBase除了登录数据库查 SQL 视图OBD 自己也有一套查询入口obd cluster list这条命令列出 OBD 管理的所有集群。然后obd cluster display 集群名会展示集群里每个组件observer、OBProxy 等的运行状态和端口信息。我个人的建议是两条通道配合着看OBD 展示的是进程和部署层面的状态SQL 视图展示的是数据库内部真正的服务状态。比如有时候进程起来了但 observer 因为某些原因没对外提供 SQL 服务这时候 OBD 显示可能是 RUNNING而START_SERVICE_TIME却是空的一对比就能发现问题。5.2 后续扩展监控、巡检、实验报告查看集群基本信息这个动作往小了说是几条命令往大了说是你后续所有运维操作的起点。做日常巡检时把第 3 节的几条 SQL 定时跑一遍节点状态、Zone 状态、租户资源水位就都有了。如果后面要做监控告警也是基于这些视图去采集数据。准备数据库课程设计、比赛答辩或者实验报告时“查看集群基本信息”这一步几乎是必写项。建议把查询结果留存下来配合版本号、部署时间一起写进文档能明显增强报告的可信度和完成度。集群迁移、数据库同步这些话题也是基于集群信息展开的你得先知道集群里有哪些节点、版本是什么、租户分布在哪才能规划迁移链路。这些都是后话本篇先把看家底的本事练好。5.3 一条实用的肌肉记忆最后分享一个我日常排查的习惯。连接上集群之后我从来不会乱翻视图而是固定按这个顺序走obclient -h127.0.0.1 -P2881 -urootsys -p -A -c进去之后先查DBA_OB_SERVERS确认节点都在线再查DBA_OB_ZONES确认 Zone 状态最后联合查询DBA_OB_TENANTS、DBA_OB_RESOURCE_POOLS、DBA_OB_UNITS看资源分布。这套流程走完整个集群的状态基本就心里有数了。后面做租户创建、扩容缩容、性能排查都是在这个基础上加东西。把这几条 SQL 存成一个.sql文件放在本地每次要查的时候直接source执行比现场敲快得多——这是我自己踩过几次坑之后总结出来的习惯希望对你有用。