分布式数据库最怕"看着正常、突然抽风"。OceanBase 这套架构（OBProxy 代理层 + OBServer 数据节点 + 多副本 Paxos）的排障思路，和单机 MySQL / Oracle 差别不小。下面 7 个场景都是真实生产里高频出现的，命令全给齐，建议先收藏照着敲。
01 连不上：先分清 OBProxy 和 OBServer 两个端口
一上来就怀疑数据库挂了，其实 80% 的"连不上"是连错端口。
-
OBProxy（代理层） ：默认 2883，应用和人应该连这里，它负责把请求路由到正确的 OBServer 和租户。
-
OBServer（数据节点） ：MySQL 租户默认 2881，一般只给运维直连做排障用。
坑点：obclient 一定要加 `-c` ，否则客户端会把 /* ... */ 这类路由 hint / 注释当废话吞掉，导致弱一致读、指定 zone 等 hint 静默失效。这和某些分布式数据库的 /*slave*/ 必须加 -c 是同一个道理。
|---------------|---------------------------------------------------------------|
| 目的 | 命令 |
| 经代理连业务租户 | obclient -h<proxy_ip> -P2883 -u<user>@<tenant> -p -c |
| 直连节点排障 | obclient -h<observer_ip> -P2881 -u<user>@<tenant> -p -c |
| 连 sys 租户做集群管理 | obclient -h<observer_ip> -P2881 -uroot@sys -p -c |
| 弱一致读 hint | SELECT /*+ read_consistency(weak) */ ... FROM t; |
「 排障顺序：先 ping 通不通 → netstat -anp | grep 2883 看端口在不在监听 → 再怀疑数据库本身。 」
02 节点要维护 / 宕机：STOP SERVER 让主副本先漂走
做硬件维护、打补丁前，别直接拔电源。OceanBase 副本基于 Paxos，停掉一个节点剩下的多数派还能对外服务，但你得先让这个节点上的主副本（Leader）主动迁走，避免切换瞬间业务抖动。
|--------------------------------|------------------------------------------------------------------------------------|
| 目的 | 命令 |
| 查看所有节点状态 | SELECT SVR_IP, SVR_PORT, STATUS, START_SERVICE_TIME FROM oceanbase.DBA_OB_SERVERS; |
| 查看 Zone 状态 | SELECT ZONE, STATUS, REGION FROM oceanbase.DBA_OB_ZONES; |
| 停节点（主副本自动迁走，port 填 RPC 口 2882） | ALTER SYSTEM STOP SERVER 'ip:2882'; |
| 维护完拉起节点 | ALTER SYSTEM START SERVER 'ip:port'; |
| 停整个 Zone | ALTER SYSTEM STOP ZONE zone_name; |
| 拉起 Zone | ALTER SYSTEM START ZONE zone_name; |
「 STOP SERVER 只是"摘流量 + 迁主"，节点进程还在；看 DBA_OB_SERVERS.stop_time 置为非 0 才算逻辑停止（INACTIVE 是 KILL SERVER 永久下线才出现，别混淆）。维护完 START SERVER 清零 stop_time、恢复服务，副本补齐再关工单。 」
03 磁盘快满：先查再用 FREEZE 合并释放
数据盘（SSTable + 转储）涨太快，最常见是转储 / 合并没跟上，或者保留的快照、副本太多。
|--------------------|-------------------------------------------------------------------------------------------------------|
| 目的 | 命令 |
| 查各节点数据盘使用 | SELECT SVR_IP, SVR_PORT, DATA_DISK_IN_USE, DATA_DISK_CAPACITY FROM oceanbase.GV$OB_SERVERS; -- 使用率自己算 |
| 触发转储（Minor Freeze） | ALTER SYSTEM MINOR FREEZE; |
| 触发合并（Major Freeze） | ALTER SYSTEM MAJOR FREEZE; |
| 看合并进度 | SELECT * FROM oceanbase.DBA_OB_COMPACTION_PROGRESS; |
「 MAJOR FREEZE 是"大合并"，会真正把增量数据落盘、回收空间，对 IO 有一定压力，建议低峰期执行。自算比例 DATA_DISK_IN_USE / DATA_DISK_CAPACITY 接近上限前就要处理，别等写满报错。 」
04 慢 SQL 抓凶手：GV$OB_SQL_AUDIT 比猜靠谱
OceanBase 自带 SQL 审计视图 GV$OB_SQL_AUDIT，记录每条 SQL 的来源、耗时、等待事件、执行计划命中情况。这是定位慢 SQL 的第一抓手。
sql
SELECT usec_to_time(request_time) AS req_time,
svr_ip, sid, db_name,
elapsed_time/1000000 AS sec, query_sql
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE tenant_id = 1001 -- 换成你的租户 ID
AND elapsed_time > 1000000 -- 大于 1 秒（单位：微秒）
ORDER BY elapsed_time DESC
LIMIT 10;
|----------------|------------------------------|
| 目的 | 命令 |
| 看执行计划 | EXPLAIN <你的SQL>; |
| 看最近一次 SQL 完整链路 | SHOW TRACE; |
| 一键开 SQL Trace | SET ob_enable_trace_log = 1; |
「 elapsed_time 是微秒 ，所以 > 1000000 才是 1 秒。审计视图有淘汰机制，访问量极大的业务可能查不到很早的 SQL，那种情况去 observer.log 里按 trace_log_slow_query_watermark（默认 1 秒）捞慢查询日志。 」
05 租户资源（CPU / 内存）打满：看 UNIT、再扩规格
OceanBase 是多租户架构，每个租户的资源来自 Resource Unit（CPU / 内存规格）和 Unit 数量。某租户把节点 CPU 跑满，本质是它的 Unit 规格不够、或 Unit 数太集中。
|-------------------|------------------------------------------------------------------------------------------|
| 目的 | 命令 |
| 查租户资源单元 | SELECT TENANT_ID, UNIT_ID, UNIT_COUNT, MAX_CPU, MEMORY_SIZE FROM oceanbase.DBA_OB_UNITS; |
| 查资源池 | SELECT * FROM oceanbase.DBA_OB_RESOURCE_POOLS; |
| 扩某 Zone 的 Unit 数量 | ALTER RESOURCE POOL rp_name UNIT_NUM = 3; |
| 看相关参数 | SHOW PARAMETERS LIKE '%cpu%'; |
「 调 UNIT_NUM 是把副本往更多节点铺开（横向扩），想加大单实例规格得改 Unit Config 再 ALTER RESOURCE POOL ... UNIT='新配置'。改资源属于高风险操作，先在测试租户验证。 」
06 副本与多数派：看懂 Leader 分布、守住高可用
OceanBase 每个分区（Tablet）有 1 个 Leader + 多个 Follower，靠 Paxos 保证"多数派写入即成功"。理解这点，排障时才不会乱。
|-----------------------------|------------------------------------------------------------------------------------------------------------------------------|
| 目的 | 命令 |
| 看某表副本的 Leader / Follower 分布 | SELECT TABLE_NAME, SVR_IP, SVR_PORT, ROLE FROM oceanbase.CDB_OB_TABLE_LOCATIONS WHERE TABLE_NAME='t' AND DATABASE_NAME='db'; |
| 看副本同步状态 | SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE TENANT_ID=1001; |
| 查集群相关参数 | SHOW PARAMETERS LIKE '%leader%'; |
「 ROLE 列 LEADER 才是接收写请求的主副本。如果某 Zone 的 Leader 过度集中、读写偏斜，靠调整 PRIMARY_ZONE 配置 + 内置均衡策略来均衡，必要时用 ALTER SYSTEM SWITCH REPLICA LEADER LS=<ls_id> SERVER='ip:port' TENANT=<tenant> 手动迁 Leader------别拿 `STOP SERVER` 来迁 Leader ，那是停机维护 / 缩容命令，副作用太大。Paxos 多数派：最多允许故障 ⌊(n-1)/2⌋ 个副本，超过这个数量分区就不可写。这是 OceanBase 高可用的根，也是 OBCP 考试副本与高可用章节的常考点。 」
07 误删数据兜底：回收站 + 闪回 + 备份三层防线
删错表 / 数据别慌，OceanBase 有几层兜底，按"最快恢复"顺序用。
|-----------------|-----------------------------------------------------------------------|
| 场景 | 命令 |
| MySQL 模式：看回收站 | SHOW RECYCLEBIN; |
| MySQL 模式：闪回删掉的表 | FLASHBACK TABLE t TO BEFORE DROP RENAME TO t_rec; |
| Oracle 模式：闪回查询 | SELECT * FROM t AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE; |
| 物理备份恢复 | 用 OCP 控制台 / obdumper + obloader 按时间点恢复 |
「 划重点：**MySQL 模式和 Oracle 模式都能用 FLASHBACK TABLE ... TO BEFORE DROP 从回收站恢复被 DROP 的表（前提是 recyclebin=ON，表才会进回收站）；DELETE 误删的行不能用 FLASHBACK TABLE，得用闪回查询 SELECT ... FROM t AS OF TIMESTAMP <t>（只读，受 undo_retention 限制）。别把闪回查询的 AS OF 和 FLASHBACK TABLE 的 TO BEFORE DROP 混为一谈。最后一道防线是物理备份，生产务必开启并定期演练恢复。 」
小结
OceanBase 运维的核心心智：代理层（OBProxy）与数据层（OBServer）分层排障 → 节点维护先迁主 → 磁盘靠 FREEZE 合并 → 慢 SQL 靠 GV$OB_SQL_AUDIT → 资源靠 UNIT → 高可用靠 Paxos 多数派 → 误删靠回收站 / 闪回 / 备份。这 7 条都是生产里真能救命的，码住不亏。