OceanBase故障排查方法论：从节点异常到数据不一致的全场景问题解决流程

一、为什么OceanBase故障排查这么重要

OceanBase作为一款分布式关系型数据库，它的架构和传统数据库（比如MySQL）有本质的区别。它把数据分散到多个节点上，靠副本机制来保证数据可用性。听起来很厉害，但这也意味着当系统出问题时，排查的复杂程度远超单机数据库。

在实际运维中，我们经常会遇到这些场景：某个节点突然挂了，剩下的节点还能正常提供服务；某个查询返回的数据和预期的不一致；某个表的主键冲突突然大量出现。这些问题如果处理不当，轻则影响业务性能，重则导致数据丢失。

这篇文章就来系统性地梳理一下OceanBase故障排查的完整方法论，从节点异常到数据不一致，覆盖各种常见场景的排查思路。不会堆砌一堆专业名词，尽量用大家都能听懂的方式来讲解。

二、节点异常排查全流程

2.1 节点异常是怎么发生的

在OceanBase中，节点异常通常表现为以下几种情况：某个节点进程崩溃、节点与集群失去网络通信、节点磁盘空间不足、节点内存使用过高。这些异常如果得不到及时处理，可能会导致副本不可用，甚至影响整个集群的写入能力。

2.2 排查第一步：查看集群健康状态

当你发现业务响应变慢或者连接报错时，第一件事就是检查集群整体健康状况。在OceanBase中，有一个核心视图GV$OB_SERVERS记录了所有节点的状态信息。

-- 查询所有节点状态信息
-- 重点关注 STATUS 字段，ACTIVE 表示节点正常，INACTIVE 表示异常
SELECT 
    SVR_IP AS 节点IP,
    SVR_PORT AS 端口,
    STATUS AS 节点状态,
    START_SERVICE_TIME AS 服务启动时间,
    LAST_OFFLINE_TIME AS 最后离线时间,
    STOP_TIME AS 停止时间
FROM GV$OB_SERVERS;

如果看到某个节点的STATUS不是ACTIVE，说明这个节点确实出了问题。接下来就需要深入排查具体原因。

2.3 排查第二步：查看节点级别的告警信息

OceanBase自带了一套告警系统，当我们怀疑节点异常时，可以通过告警表来查看近期有哪些异常事件被记录下来。

-- 查询最近的告警信息
-- 按告警级别排序，严重级别优先
-- WHERE条件可以按时间范围筛选，避免查询数据量过大
SELECT 
    ALERT_NAME AS 告警名称,
    ALERT_LEVEL AS 告警级别,
    SVR_IP AS 触发节点,
    ALERT_MSG AS 告警详情,
    STATUS AS 告警状态,
    CREATE_TIME AS 创建时间,
    UPDATE_TIME AS 更新时间
FROM GV$OB_ALERT_HISTORY
WHERE STATUS = 'ALARM'
ORDER BY ALERT_LEVEL, CREATE_TIME DESC
LIMIT 50;

常见的节点异常告警包括OB_SERVER_DOWN（节点宕机）、OB_SERVER_DISK_FULL（磁盘空间不足）、OB_SERVER_MEM_EXCEEDED（内存超限）等。每一条告警都对应着不同的排查方向。

2.4 排查第三步：查看节点日志定位根因

告警信息只能告诉我们"出了什么问题"，但"为什么出问题"需要从日志中找答案。OceanBase的日志分为几种类型：

# 技术栈：OceanBase数据库运维
# 进入节点日志目录，查看最近的error日志
# 通常日志路径在 /data/1/log/ 下
# 使用 grep 过滤关键字进行快速定位

# 查看最近500行的错误日志
tail -n 500 /data/1/log/observer.log | grep -i "ERROR"

# 查看最近的告警日志
tail -n 500 /data/1/log/observer.log.wf | grep -i "WARN"

# 查找节点宕机相关的日志记录
grep -i "server.*down\|crash\|fatal" /data/1/log/observer.log | tail -n 100

日志中的关键字要特别关注。比如出现REPLICA_SYNC_TIMEOUT表示副本同步超时，出现CHECKSUM_MISMATCH表示数据校验失败，出现DISK_FULL表示磁盘空间不足。

2.5 节点异常处理方案

确认问题原因后，需要根据具体情况采取不同的处理措施：

-- 技术栈：OceanBase数据库运维

-- 场景1：节点磁盘空间不足，需要清理空间
-- 先查看各节点的磁盘使用率
SELECT 
    SVR_IP,
    DISK_CAPACITY,
    DISK_USED,
    DISK_FREE,
    ROUND(DISK_USED / DISK_CAPACITY * 100, 2) AS 使用率百分比
FROM GV$OB_SERVERS;

-- 场景2：确认节点已经无法恢复，需要从集群中移除
-- 先检查该节点上的副本状态
SELECT 
    TENANT_ID AS 租户ID,
    TABLET_ID AS 表片ID,
    SVR_IP AS 所在节点,
    ROLE AS 副本角色,
    SYNC_SCN AS 同步位点
FROM GV$OB_TABLET_REPLICA
WHERE SVR_IP = '10.0.0.2';  -- 替换为问题节点的IP

-- 场景3：节点恢复后需要重新加入集群
-- 确认节点状态恢复正常后，检查副本是否自动恢复
SELECT 
    COUNT(*) AS 总副本数,
    SUM(CASE WHEN ROLE = 'LEADER' THEN 1 ELSE 0 END) AS Leader数量,
    SUM(CASE WHEN ROLE = 'FOLLOWER' THEN 1 ELSE 0 END) AS Follower数量
FROM GV$OB_TABLET_REPLICA;

2.6 节点异常的预防措施

# 技术栈：OceanBase数据库运维

# 设置磁盘使用率监控告警，超过80%触发告警
# 这里使用一个示例的监控脚本来演示

cat << 'EOF' > /opt/scripts/oceanbase_monitor.sh
#!/bin/bash

# OceanBase节点磁盘监控脚本
# 用途：定期检查节点磁盘使用情况，超过阈值发送告警

OBSERVER_HOST="10.0.0.1"
OBSERVER_PORT="2881"
ALERT_THRESHOLD=80  # 磁盘使用率告警阈值

# 连接数据库查询磁盘使用情况
DISK_USAGE=$(mysql -h $OBSERVER_HOST -P $OBSERVER_PORT -uroot@sys -e "
SELECT DISK_USED / DISK_CAPACITY * 100 
FROM GV$OB_SERVERS 
WHERE SVR_IP = '$OBSERVER_HOST';" 2>/dev/null)

# 判断是否超过阈值
if (( $(echo "$DISK_USAGE > $ALERT_THRESHOLD" | bc -l) )); then
    echo "警告：节点 $OBSERVER_HOST 磁盘使用率达到 ${DISK_USAGE}%，已超过 ${ALERT_THRESHOLD}% 阈值！"
    # 这里可以添加邮件或钉钉告警的调用
fi
EOF

chmod +x /opt/scripts/oceanbase_monitor.sh
# 设置crontab每5分钟执行一次
# crontab -e 添加：*/5 * * * * /opt/scripts/oceanbase_monitor.sh >> /var/log/oceanbase_monitor.log 2>&1

三、数据不一致问题排查

3.1 数据不一致的常见表现

数据不一致是分布式数据库中让人最头疼的问题。在OceanBase中，数据不一致可能表现为以下几种情况：主从数据不同步、同一个事务在不同副本上返回不同的查询结果、事务提交后部分数据未生效、历史数据与当前数据校验失败。

3.2 排查数据一致性：检查副本同步状态

在OceanBase中，数据副本之间通过LSM-Tree的增量同步来保持一致性。当副本同步出现问题时，数据就可能出现不一致。

-- 技术栈：OceanBase数据库运维

-- 检查各副本之间的同步延迟
-- SYNC_SCN字段记录了副本同步到的位点
-- LEADER_SCN是Leader的当前位点，两者差异越大，延迟越严重
SELECT 
    TABLET_ID AS 表片ID,
    LEADER_SVR_IP AS Leader节点,
    LEADER_SYNC_SCN AS Leader同步位点,
    FOLLOWER_SVR_IP AS Follower节点,
    FOLLOWER_SYNC_SCN AS Follower同步位点,
    (LEADER_SYNC_SCN - FOLLOWER_SYNC_SCN) AS 同步差距
FROM GV$OB_TABLET_REPLICA
WHERE TABLET_ID = 200001;  -- 替换为需要检查的表片ID

-- 检查副本的同步状态是否为正常
-- SYNC_STATUS: NORMAL 表示正常同步，ABNORMAL 表示异常
SELECT 
    TENANT_ID,
    TABLET_ID,
    SVR_IP,
    ROLE,
    SYNC_STATUS,
    LAST_SYNC_TIME
FROM GV$OB_TABLET_REPLICA
WHERE SYNC_STATUS != 'NORMAL';

3.3 数据一致性校验

OceanBase提供了数据校验的功能，通过对比不同副本的数据内容来检测不一致。

-- 技术栈：OceanBase数据库运维

-- 发起数据一致性校验任务
-- 这里以业务表为例，检查数据是否在所有副本上一致
-- 需要先将校验数据导入临时表进行比对

-- 步骤1：查看表的分片信息和副本分布
SELECT 
    TABLE_ID,
    TABLE_NAME,
    TABLEGROUP_ID,
    TABLE_SCHEMA_VERSION,
    DATA_TABLE_ID
FROM OCEANBASE.DBA_OB_TABLES
WHERE TABLE_NAME = 'orders';  -- 替换为实际表名

-- 步骤2：对可疑数据执行校验
-- 通过checksum来比较不同副本的数据一致性
SELECT 
    TABLET_ID,
    SVR_IP,
    ROLE,
    CHECKSUM_VALUE,
    CHECKSUM_VERSION
FROM GV$OB_TABLET_CHECKSUM
WHERE TABLE_ID = 200001;  -- 替换为实际的表ID

-- 步骤3：如果发现不一致，可以手动触发副本同步
-- 切换Leader到健康的副本
ALTER SYSTEM SWITCH REPLICA 
    TABLET_ID = 200001 
    LEADER_SVR_IP = '10.0.0.3';  -- 切换到健康的Follower

3.4 事务级别的数据一致性排查

当事务级别出现数据不一致时，需要检查事务的状态和日志：

-- 技术栈：OceanBase数据库运维

-- 查看活跃事务的状态
-- 重点关注事务是否长时间未完成，可能导致数据不一致
SELECT 
    TENANT_ID AS 租户ID,
    TX_ID AS 事务ID,
    PARTICIPANT AS 参与者列表,
    STATE AS 事务状态,
    CREATED AS 创建时间,
    ELAPSED_TIME AS 已耗时(微秒),
    COMMIT_TIME AS 提交时间
FROM GV$OB_TRANSACTION_PARTICIPANT
WHERE STATE != 'COMMITTED' 
ORDER BY ELAPSED_TIME DESC
LIMIT 20;

-- 查看事务的日志信息，确认事务是否完整提交
SELECT 
    TENANT_ID,
    LSN,
    TX_ID,
    TYPE,
    STATUS,
    COMMIT_TIME
FROM GV$OB_TRANSACTION_LOG
WHERE TX_ID = 123456789;  -- 替换为可疑的事务ID

3.5 数据不一致的修复流程

# 技术栈：OceanBase数据库运维

# 发现数据不一致后的修复操作示例

# 步骤1：确认不一致范围
# 先通过校验找到具体哪些表片有问题
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
SELECT TABLET_ID, SVR_IP, ROLE, CHECKSUM_VALUE 
FROM GV$OB_TABLET_CHECKSUM 
WHERE TABLE_ID = 200001;"

# 步骤2：确认Leader副本的数据完整性
# 如果Leader正常，优先切换到Leader所在节点
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
SELECT TABLET_ID, SVR_IP, ROLE 
FROM GV$OB_TABLET_REPLICA 
WHERE TABLET_ID = 200001 
ORDER BY ROLE;"

# 步骤3：执行副本重建
# 对异常的副本执行rebuild操作，从其他副本重新同步数据
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
ALTER SYSTEM REBUILD REPLICA 
    TABLET_ID = 200001 
    SVR_IP = '10.0.0.2';"

# 步骤4：验证修复结果
# 再次执行校验确认数据一致性已恢复
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
SELECT TABLET_ID, SVR_IP, ROLE, CHECKSUM_VALUE 
FROM GV$OB_TABLET_CHECKSUM 
WHERE TABLE_ID = 200001;"

四、性能相关故障排查

4.1 慢查询定位

当业务反馈响应变慢时，第一步就是要找到慢查询的源头。OceanBase中有一些视图专门用于记录慢查询信息。

-- 技术栈：OceanBase数据库运维

-- 查看最近的慢查询记录
-- 重点关注执行时间较长、扫描数据量较大的SQL
SELECT 
    TENANT_ID AS 租户ID,
    SVR_IP AS 执行节点,
    SQL_ID AS SQL标识,
    ELAPSED_TIME AS 执行耗时(微秒),
    EXECUTE_TIMES AS 执行次数,
    ROWS_EXAMINED AS 扫描行数,
    SUBSTR(SQL_TEXT, 1, 200) AS SQL语句
FROM GV$SQL_AUDIT
WHERE ELAPSED_TIME > 1000000  -- 大于1秒的慢查询
  AND TENANT_ID = 1002  -- 指定租户
ORDER BY ELAPSED_TIME DESC
LIMIT 20;

4.2 资源瓶颈分析

性能问题很多时候是因为某个资源（CPU、内存、IO）达到了瓶颈。OceanBase中可以通过相关视图来分析资源使用情况。

-- 技术栈：OceanBase数据库运维

-- 查看各租户的资源使用情况
SELECT 
    TENANT_ID AS 租户ID,
    TENANT_NAME AS 租户名称,
    CPU_USAGE AS CPU使用率,
    MEM_USAGE AS 内存使用量(MB),
    DISK_USAGE AS 磁盘使用量(MB),
    IOPS_USAGE AS IO使用量
FROM GV$OB_TENANT_RESOURCE
ORDER BY CPU_USAGE DESC;

-- 查看SQL执行计划的资源消耗
-- 帮助定位是SQL写法问题还是资源不足
SELECT 
    SQL_ID,
    ELAPSED_TIME,
    CPU_TIME,
    IO_WAIT_TIME,
    SCHEDULE_TIME,
    NET_WAIT_TIME,
    SUBSTR(SQL_TEXT, 1, 300)
FROM GV$OB_PLAN_CACHE_PLAN_STAT
WHERE SQL_ID = 'abc123';  -- 替换为实际的SQL ID

4.3 内存相关问题排查

内存泄漏或内存碎片是OceanBase中比较常见的问题。

-- 技术栈：OceanBase数据库运维

-- 查看内存使用分布
-- 帮助判断是否有内存异常增长的情况
SELECT 
    MOD_NAME AS 内存模块,
    SUM(ALLOC_SIZE) AS 分配大小(B),
    SUM(FREE_SIZE) AS 空闲大小(B),
    ROUND(SUM(ALLOC_SIZE) / SUM(ALLOC_SIZE + FREE_SIZE) * 100, 2) AS 使用率
FROM GV$OB_MEMORY
GROUP BY MOD_NAME
ORDER BY 分配大小(B) DESC
LIMIT 20;

-- 查看特定租户的内存使用详情
SELECT 
    TENANT_ID,
    MOD_NAME,
    ALLOC_SIZE,
    FREE_SIZE,
    CHARGE_ITEM AS 费用项
FROM GV$OB_MEMORY
WHERE TENANT_ID = 1002
ORDER BY ALLOC_SIZE DESC;

4.4 并发锁冲突排查

在高并发场景下，锁竞争是性能下降的常见原因。

-- 技术栈：OceanBase数据库运维

-- 查看当前锁等待的情况
SELECT 
    TENANT_ID AS 租户ID,
    TX_ID AS 持有锁的事务ID,
    TX_TYPE AS 事务类型,
    OBJ_TYPE AS 对象类型,
    OBJ_ID AS 对象ID,
    LOCK_MODE AS 锁模式,
    WAIT_TIME AS 等待时间(微秒),
    SUBSTR(SQL_TEXT, 1, 200) AS 等待SQL
FROM GV$OB_LOCK_WAIT_STAT
ORDER BY WAIT_TIME DESC
LIMIT 20;

-- 查看事务冲突信息
SELECT 
    TX_ID AS 事务ID,
    TX_STATUS AS 事务状态,
    TX_TYPE AS 事务类型,
    START_TIME AS 开始时间,
    COMMIT_TIME AS 提交时间,
    CONFLICT_TX_IDS AS 冲突事务列表
FROM GV$OB_TRANSACTION_STATUS
WHERE TENANT_ID = 1002
  AND TX_STATUS = 'LOCK_WAIT';

五、备份恢复故障排查

5.1 备份状态检查

OceanBase支持全量备份和增量备份，备份过程中同样可能出现故障。定期检查和确认备份状态是运维的基本要求。

-- 技术栈：OceanBase数据库运维

-- 查看备份任务的执行状态
SELECT 
    TENANT_ID AS 租户ID,
    BACKUP_SET_ID AS 备份集ID,
    BACKUP_TYPE AS 备份类型,
    STATUS AS 备份状态,
    START_TIME AS 开始时间,
    END_TIME AS 结束时间,
    ELAPSED_TIME AS 耗时(微秒),
    RESULT AS 执行结果
FROM GV$OB_BACKUP_JOB
ORDER BY START_TIME DESC
LIMIT 20;

-- 查看备份日志中是否有错误
SELECT 
    TENANT_ID,
    BACKUP_SET_ID,
    BACKUP_LEVEL AS 备份级别,
    STATUS,
    ERROR_CODE AS 错误码,
    ERROR_MSG AS 错误信息
FROM GV$OB_BACKUP_JOB_HISTORY
WHERE STATUS = 'FAILED'
ORDER BY START_TIME DESC
LIMIT 20;

5.2 恢复操作故障排查

# 技术栈：OceanBase数据库运维

# 当恢复操作失败时的排查步骤

# 步骤1：查看恢复任务的详细日志
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
SELECT 
    RESTORE_TASK_ID,
    RESTORE_TYPE,
    STATUS,
    START_TIME,
    END_TIME,
    ERROR_CODE,
    ERROR_MSG
FROM GV$OB_RESTORE_JOB
WHERE STATUS = 'FAILED'
ORDER BY START_TIME DESC;"

# 步骤2：检查备份数据文件的完整性
# 登录到备份存储服务器，检查备份文件
ls -la /backup/oceanbase/tenant_1002/

# 步骤3：查看备份元数据是否完整
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
SELECT 
    BACKUP_SET_ID,
    BACKUP_LEVEL,
    BACKUP_SET_STATUS,
    FILE_COUNT,
    TOTAL_SIZE
FROM GV$OB_BACKUP_SET
WHERE TENANT_ID = 1002
ORDER BY BACKUP_SET_ID DESC;"

# 步骤4：如果元数据有问题，可以重新注册备份
mysql -h 10.0.0.1 -P 2881 -uroot@sys -e "
ALTER SYSTEM RECOVER BACKUP SET;
"

5.3 恢复流程示例

-- 技术栈：OceanBase数据库运维

-- 完整的恢复操作示例
-- 场景：需要将数据库恢复到指定时间点

-- 步骤1：创建恢复租户
CREATE RESTORE TENANT restore_tenant
    RESOURCE_POOL_LIST = ('rp1', 'rp2')
    TIME_ZONE = '+8:00'
    PRIMARY_ZONE = 'zone1,zone2,zone3'
    LOCALITY = 'FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3';

-- 步骤2：查看可用的备份集
SELECT 
    BACKUP_SET_ID,
    BACKUP_LEVEL,
    BACKUP_SET_STATUS,
    START_TIME,
    END_TIME
FROM GV$OB_BACKUP_SET
WHERE TENANT_ID = 1002;

-- 步骤3：发起恢复任务
-- 恢复到指定时间点 2024-01-15 10:30:00
ALTER SYSTEM RESTORE DATABASE restore_tenant
    FROM 's3://backup-bucket/oceanbase/tenant_1002'
    UNTIL '2024-01-15 10:30:00';

-- 步骤4：监控恢复进度
SELECT 
    RESTORE_TASK_ID,
    TENANT_ID,
    STATUS,
    START_TIME,
    END_TIME,
    ELAPSED_TIME,
    RESULT
FROM GV$OB_RESTORE_JOB;

六、应用场景分析

6.1 互联网高并发业务场景

在互联网业务中，OceanBase常用于支撑百万级QPS的写入和读取操作。故障排查时，需要特别关注以下几个方面：

连接数异常：当业务流量突增时，连接数会急剧上升。可以通过以下查询来监控：

-- 技术栈：OceanBase数据库运维

-- 查看各租户的连接数使用情况
SELECT 
    TENANT_ID,
    TENANT_NAME,
    ACTIVE_SESSION AS 活跃会话数,
    MAX_SESSION AS 最大会话数,
    ROUND(ACTIVE_SESSION / MAX_SESSION * 100, 2) AS 连接使用率
FROM GV$OB_TENANT_SESSION
ORDER BY 连接使用率 DESC;

-- 查看连接来源分布
SELECT 
    CLIENT_IP AS 客户端IP,
    COUNT(*) AS 连接数量,
    TENANT_ID
FROM GV$OB_SYS_SESSION
GROUP BY CLIENT_IP, TENANT_ID
ORDER BY 连接数量 DESC
LIMIT 20;

长事务监控：在互联网业务中，长事务可能导致锁持有时间过长，影响整体性能：

-- 技术栈：OceanBase数据库运维

-- 检测运行超过5分钟的长事务
SELECT 
    TENANT_ID,
    TX_ID,
    ELAPSED_TIME / 1000000 AS 已运行时间(秒),
    STATE AS 事务状态,
    SUBSTR(STATE, 1, 50) AS 状态详情
FROM GV$OB_TRANSACTION_PARTICIPANT
WHERE ELAPSED_TIME > 300000000  -- 大于5分钟
  AND STATE != 'COMMITTED'
ORDER BY ELAPSED_TIME DESC;

6.2 金融级事务场景

金融场景对数据一致性要求极高，故障排查时需要更加谨慎：

-- 技术栈：OceanBase数据库运维

-- 查看事务的隔离级别配置
SELECT 
    TENANT_ID,
    TENANT_NAME,
    DEFAULT_ISOLATION AS 默认隔离级别,
    ALLOWED_ISOLATION_LEVELS AS 允许的隔离级别
FROM GV$OB_TENANT;

-- 检查事务中是否存在异常回滚
SELECT 
    TENANT_ID,
    TX_ID,
    TX_TYPE,
    STATE,
    ABORT_TIME,
    ABORT_REASON AS 回滚原因
FROM GV$OB_TRANSACTION_STATUS
WHERE STATE = 'ABORTED'
  AND ABORT_TIME > TIMESTAMP '2024-01-15 00:00:00'
ORDER BY ABORT_TIME DESC
LIMIT 20;

6.3 大数据量场景

当表数据量达到千万甚至亿级时，故障排查的侧重点不同：

-- 技术栈：OceanBase数据库运维

-- 查看大表的分区信息和数据分布
SELECT 
    TABLE_ID,
    TABLE_NAME,
    TABLEGROUP_ID,
    PARTITION_COUNT AS 分区数量,
    DATA_TABLE_ID,
    ROW_COUNT_ESTIMATE AS 预估行数
FROM OCEANBASE.DBA_OB_TABLES
WHERE TABLE_NAME = 'orders'
  AND ROW_COUNT_ESTIMATE > 10000000;

-- 查看大表的执行计划是否合理
SELECT 
    SQL_ID,
    ELAPSED_TIME,
    COST,
    SUBSTR(PLAN_EXPLAIN, 1, 500) AS 执行计划
FROM GV$OB_PLAN_CACHE_PLAN_STAT
WHERE SQL_TEXT LIKE '%orders%'
ORDER BY ELAPSED_TIME DESC
LIMIT 5;

七、技术优缺点分析

7.1 优势方面

OceanBase的分布式架构和副本机制提供了以下几个核心优势：

高可用性：通过多副本机制，即使部分节点故障，系统依然可以正常提供服务。排查故障时，只需要关注故障节点本身，不需要担心整个系统不可用。

自动故障转移：当一个Leader副本故障时，OceanBase会自动选举新的Leader。排查时可以通过以下查询确认切换情况：

-- 技术栈：OceanBase数据库运维

-- 查看Leader切换的历史记录
SELECT 
    TABLET_ID,
    SVR_IP AS 原Leader节点,
    NEW_LEADER_SVR_IP AS 新Leader节点,
    SWITCH_TIME AS 切换时间,
    SWITCH_TYPE AS 切换类型
FROM GV$OB_TABLET_LEADER_SWITCH
WHERE SWITCH_TIME > TIMESTAMP '2024-01-01 00:00:00'
ORDER BY SWITCH_TIME DESC
LIMIT 20;

数据强一致性：OceanBase采用Paxos协议来保证数据一致性，在排查数据不一致问题时，有明确的一致性保证作为参考基准。

7.2 劣势方面

排查复杂度较高：分布式系统本身就有复杂性，排查问题时往往需要从多个维度入手，而不是像单机MySQL那样只需要看进程和日志。

学习成本：OceanBase的视图体系庞大，排查时需要熟悉大量的系统视图。建议建立自己的常用查询清单：

-- 技术栈：OceanBase数据库运维

-- 常用排查视图速查表
-- 节点状态：GV$OB_SERVERS
-- 租户信息：GV$OB_TENANTS
-- 表信息：DBA_OB_TABLES
-- 副本信息：GV$OB_TABLET_REPLICA
-- 事务信息：GV$OB_TRANSACTION_STATUS
-- 锁信息：GV$OB_LOCK_WAIT_STAT
-- 性能审计：GV$SQL_AUDIT
-- 内存信息：GV$OB_MEMORY
-- 备份信息：GV$OB_BACKUP_JOB
-- 恢复信息：GV$OB_RESTORE_JOB

-- 示例：一表清查询，快速了解集群整体状况
SELECT 
    '=== 集群概况 ===' AS 信息类型,
    COUNT(*) AS 节点数量
FROM GV$OB_SERVERS

UNION ALL

SELECT 
    '活跃租户数' AS 信息类型,
    COUNT(*) AS 数量
FROM GV$OB_TENANTS

UNION ALL

SELECT 
    '活跃事务数' AS 信息类型,
    COUNT(*) AS 数量
FROM GV$OB_TRANSACTION_PARTICIPANT

UNION ALL

SELECT 
    '锁等待数' AS 信息类型,
    COUNT(*) AS 数量
FROM GV$OB_LOCK_WAIT_STAT;

文档和工具不完善：相比MySQL生态，OceanBase的第三方工具和支持文档相对较少，很多排查工作依赖于官方视图和内置命令。

八、注意事项

8.1 排查时的安全规范

在进行故障排查时，有几个安全原则必须遵守：

避免生产环境执行危险操作：排查过程中如果需要执行ALTER、DROP等操作，一定要先备份确认：

-- 技术栈：OceanBase数据库运维

-- 执行危险操作前的安全检查
-- 1. 确认操作影响范围
SELECT 
    TENANT_ID,
    TENANT_NAME,
    STATUS
FROM GV$OB_TENANTS
WHERE TENANT_ID = 1002;

-- 2. 确认是否有活跃事务
SELECT COUNT(*) AS 活跃事务数
FROM GV$OB_TRANSACTION_PARTICIPANT
WHERE TENANT_ID = 1002
  AND STATE NOT IN ('COMMITTED', 'ABORTED');

-- 3. 确认是否有锁等待
SELECT COUNT(*) AS 锁等待数
FROM GV$OB_LOCK_WAIT_STAT
WHERE TENANT_ID = 1002;

-- 4. 确认副本同步状态
SELECT 
    TABLET_ID,
    SYNC_STATUS
FROM GV$OB_TABLET_REPLICA
WHERE TENANT_ID = 1002
  AND SYNC_STATUS != 'NORMAL';

操作前先确认影响范围：任何变更操作都需要先在测试环境验证，确认不会导致数据丢失或服务中断。

8.2 日志管理的注意事项

# 技术栈：OceanBase数据库运维

# 日志轮转和清理操作
# OceanBase日志默认保存在 /data/1/log/ 目录下
# 如果日志过多会影响磁盘空间，需要定期清理

# 查看日志目录大小
du -sh /data/1/log/

# 查看日志文件列表和修改时间
ls -la /data/1/log/ | sort -k6,7

# 清理7天前的日志文件（谨慎操作！先确认不需要保留）
find /data/1/log/ -name "*.log*" -mtime +7 -exec ls -la {} \;
# 确认无误后再执行删除
# find /data/1/log/ -name "*.log*" -mtime +7 -delete

# 压缩旧日志以节省空间
gzip /data/1/log/observer.log.20240101

8.3 性能影响评估

排查操作本身也可能对系统性能产生影响。查询大量数据时需要限制返回量：

-- 技术栈：OceanBase数据库运维

-- 查询数据量大的视图时，务必加上LIMIT限制
-- 错误示范：直接全量查询（可能导致性能问题）
-- SELECT * FROM GV$SQL_AUDIT;  -- 不要这样做！

-- 正确示范：加上时间范围和LIMIT
SELECT 
    SQL_ID,
    ELAPSED_TIME,
    SUBSTR(SQL_TEXT, 1, 100)
FROM GV$SQL_AUDIT
WHERE TENANT_ID = 1002
  AND REQUEST_TIME > TIMESTAMP '2024-01-15 00:00:00'
ORDER BY ELAPSED_TIME DESC
LIMIT 50;  -- 必须加LIMIT限制

8.4 权限管理

排查工作需要特定的系统权限，不同角色能看到的视图不同：

-- 技术栈：OceanBase数据库运维

-- 创建只读排查账号，限制权限
CREATE USER IF NOT EXISTS observer_check IDENTIFIED BY 'Str0ngP@ssw0rd!';
GRANT SELECT ON OCEANBASE.* TO observer_check;
GRANT SELECT ON SYS.* TO observer_check;

-- 排查完成后，如果账号不再需要，及时删除
-- DROP USER observer_check;

九、文章总结

OceanBase的故障排查是一个系统性的工作，需要从多个维度来综合判断。从节点异常到数据不一致，从性能问题到备份恢复，每个环节都有其特定的排查方法和工具。

掌握OceanBase故障排查的关键在于以下几点：

第一，建立系统性的排查思路。不要一遇到问题就盲目操作，而是按照"现象→定位→确认→修复→验证"的流程来推进。先从整体健康状况开始检查，逐步缩小问题范围。

第二，熟悉核心系统视图。本文介绍的大量系统视图是排查工作的基础工具，建议在实际工作中建立自己的常用视图查询清单，遇到类似问题时能够快速调取相关信息。

第三，做好操作记录和复盘。每一次故障排查都应该形成完整的记录，包括问题现象、排查过程、根因分析、解决方案和预防措施。这些经验积累下来，下次遇到类似问题时就能快速定位。

第四，预防措施优于事后排查。通过监控告警、定期健康检查、容量规划等手段，可以在问题发生之前将其消除。一个设计良好的监控系统能够在异常刚出现时就发出告警，大大缩短故障恢复时间。

第五，保持对技术更新的关注。OceanBase的版本迭代较快，不同版本之间的系统视图和行为可能有所不同。建议关注官方文档和社区动态，及时了解新功能和新排查方法。

在实际运维中，故障排查能力是需要不断积累的。每一次故障都是学习和成长的机会，通过持续地总结和改进，排查效率会越来越高的。