背景介绍

OB（OceanBase）服务器在日常运行中，可能会遇到各种问题，如连接异常、进程异常退出、合并问题、事务问题和副本迁移问题等，本文旨在为OB服务器问题的排查提供一份详细的指南，重点介绍如何系统性地诊断和解决这些问题。

章节一：OB服务器概述

OB服务器即OceanBase服务器，是蚂蚁金服自主研发的分布式关系数据库，OB具有高性能、高可用、高扩展等特点，广泛应用于金融、电信、政务等领域，在实际运行过程中，OB服务器不可避免地会出现各种问题，需要及时有效地进行排查和解决。

章节二：常见问题及排查方法

连接问题

1.1 OBProxy和应用之间的连接异常

OBProxy是OB数据库的代理层，负责转发客户端请求并路由到具体的OBServer，当应用无法连接到数据库时，首先应检查OBProxy是否正常工作，可以通过以下步骤进行检查：

- 尝试通过OBProxy连接数据库，查看是否能成功连接。

- 如果无法通过OBProxy连接，再尝试直连OceanBase数据库，以确定问题是否出在OBProxy上。

- 查看报错信息，常见的报错类型包括数据库事务状态异常导致OB主动断开连接，应用端连接报错等，如果报错信息涉及“Get connection timeout”及连接数，应查看应用是否有流量突增或DB连接数设置不当；如果报错信息涉及“Communications link failure”，则可能是连接被异常中断。

1.2 OBProxy和OBServer之间连接异常

如果确定OBProxy正常工作，但应用仍然无法连接，则需要检查OBProxy和OBServer之间的连接，具体步骤如下：

- 确认OBServer进程是否正常启动，可以通过操作系统命令（如ps -ef）查看OBServer进程是否存在。

- 如果OBServer进程不存在，且不是硬件损坏或操作系统问题，可以尝试手动拉起observer进程作为应急手段。

- 检查OBServer日志，位于OCP告警事件页面，查看是否有相关的ERROR日志。

- 如果OBServer进程存在但连接异常，可以通过查看core dump文件进行根因分析，使用addr2line工具可以解析core dump文件中的地址信息，获得CRAS原始信息和线程栈信息。

OBServer进程异常退出

当正在运行的OBServer异常退出时，需要快速定位问题并恢复服务，具体步骤如下：

- 通过操作系统命令（如ps -ef）查询OBServer进程是否存在，如果进程不存在，首先排除硬件损坏和操作系统问题。

- 尝试手动启动OBServer进程，命令如下：

  su - admin
  cd /home/admin/oceanbase && bin/observer

- 如果手动启动失败，检查OBServer日志和core dump文件，分析错误原因。

- 如果OBServer频繁异常退出，建议检查系统资源使用情况，如CPU、内存、磁盘IO等，确保系统资源充足。

合并问题

OceanBase在数据合并过程中可能会出现各种问题，如合并超时、合并慢等，以下是合并问题的详细排查方法：

3.1 未合并问题

ZONE未合并：执行以下SQL查询未合并的ZONE：

  SELECT * FROM __all_zone WHERE name = "global_broadcast_version" or name = "broadcast_version";

如果broadcast_version等于last_merged_version，且last_merged_version落后于global_broadcast_version，说明RootService没有发起相关Zone的合并。

副本未合并：执行以下SQL查询未合并的副本：

  SELECT * FROM __all_virtual_meta_table WHERE data_version != 25 LIMIT 10;

3.2 合并超时问题

- 定位未合并到指定版本的partition：

  SELECT * FROM __all_zone WHERE name = "frozen_version" or name = "last_merged_version";

- 判断该partition的合并任务是否在执行中：

  SELECT * FROM __all_virtual_sys_task_status;

- 如果该partition没有调度合并任务，判断该partition的最新的转储sstable的snapshot_version是否推过freeze_info点，如果没有推过freeze_info点，说明转储有问题。

3.3 合并慢问题

- 找到合并耗时最多的几个partition：

  SELECT /*+ query_timeout(10000000)*/* FROM __all_virtual_partition_sstable_merge_info WHERE merge_type = "major merge" and version = "<merge_version>" ORDER BY merge_cost_time desc limit 5;

- 通过表__all_virtual_partition_sstable_merge_info查看宏块重用情况。

- 查看合并开始时间是否合理。

事务问题

OceanBase在执行数据库事务时，可能会出现各种事务问题，如事务回滚、执行超时、等待锁超时等，以下是事务问题的详细排查方法：

- 通过__all_virtual_trans_stat表查询当前还未结束的事务上下文状态。

- 根据trans_id搜索对应时间段内的observer.log日志，找到相应事务报错信息。

- 根据错误标识位（如4038）判断问题是否属于事务回滚类、执行超时类、等待锁超时类等类型。

副本迁移问题

OceanBase在副本迁移过程中也可能出现各种问题，以下是副本迁移问题的详细排查方法：

迁入目标端磁盘满：执行以下SQL查询有迁移异常的server：

  SELECT * FROM __all_server WHERE block_migrate_in_time > NOW();

迁入目标端响应慢：通常由于网络问题或目标端负载高导致，可以使用ping命令测试网络连通性，或者查看目标端的系统负载。

迁入目标端拒绝迁入：可能是由于权限问题或配置问题导致，可以检查用户权限和配置文件是否正确。

迁入目标端故障：可能是由于目标端服务器宕机或重启导致，可以查看目标端的系统日志，确认是否有异常。

迁入目标端空间不足：执行以下SQL查询剩余空间最小的server：

  SELECT * FROM __all_store_status ORDER BY remaining_size ASC LIMIT 1;

AGENT进程异常退出：可能是由于进程异常导致，可以查看AGENT日志，确认是否有异常信息。

AGENT部署失败：可能是由于配置文件错误或依赖包缺失导致，可以检查AGENT的配置文件和依赖包是否正确。

AGENT端口被占用：可能是由于端口冲突导致，可以查看系统端口使用情况，确认AGENT端口是否被其他进程占用。

AGENT启动失败：可能是由于配置文件错误或依赖包缺失导致，可以检查AGENT的配置文件和依赖包是否正确。

AGENT运行不正常：可能是由于系统资源不足或进程异常导致，可以查看系统资源使用情况，确认AGENT进程是否正常。

AGENT状态异常：可能是由于网络问题或配置问题导致，可以查看AGENT状态，确认是否有异常。

章节三：高级排查技巧

OCP告警事件页面

OCP告警事件页面是OceanBase集群管理和监控的重要工具，可以实时查看集群的健康状态和告警信息，当OB服务器出现问题时，首先应查看OCP告警事件页面，确认是否有相关的ERROR日志告警。

SQL查询和日志分析

SQL查询和日志分析是排查OB服务器问题的关键手段，通过执行特定的SQL语句，可以查询集群的各种状态信息；通过分析日志文件，可以了解OBServer的运行情况和错误原因，常用的日志文件包括observer.log、obproxy.log、rootservice.log等。

Core Dump分析

当OBServer进程异常退出时，会生成core dump文件，Core dump文件包含了进程崩溃时的内存映像和调试信息，可以帮助开发人员定位问题根源，使用gdb和addr2line工具可以解析core dump文件，获得函数调用栈和崩溃点的详细信息。

系统资源监控

系统资源监控是保障OB服务器稳定运行的重要手段，通过监控CPU、内存、磁盘IO、网络等系统资源，可以及时发现性能瓶颈和异常情况，常用的监控工具包括top、vmstat、iostat、ifconfig等。

章节四：实际案例分析

案例一：OB服务器无法连接

某公司部署了一套1-1-1模式的OB测试环境，在没关集群