公有云 OBServer 节点频繁 inactive

问题现象

公有云环境出现 OBServer inavtive 告警，从 __all_rootservice_event_history 表可以看到固定有一个节点存在多次上下线记录。

关键诊断信息

触发条件

OBServer RPC 使用的一个 tcp socket 连接出现了异常，单向的数据传输 hung 住或者可用带宽很低。

事前巡检

无。

事后诊断

在 inactive 的 OBServer 上，在 inactive 时间段的 OBServer 日志中搜索 delay_warn，如果出现大量的 pkts_flush_cb delay high 日志，并且线程 id 都是同一个同一个线程，同时 delay high 的值接近于 3000000、9000000 这样的 1000000 整数倍的有规律的值。

此外，搜索 PNIO rpc resp is expired 也能匹配到大量 WDIAG 日志，并且日志中的 sock_id 都是同一个。

满足上述条件，就说明是遇到了这个问题。如果搜索 delay_warn 还有其它 WDIAG 日志，说明是其它原因导致 RPC 耗时长从而出现 inactive，需要结合日志和环境监控进一步排查（比如检查是否是网络带宽被打满、网络延迟或者丢包增加、或者操作系统的可用内存不足）。

问题原因

网络问题导致 tcp 连接 hung 住或者可用带宽很低，同时 OBServer 中对于这种情况的连接没有及时断连接，导致上层的部分 RPC 持续失败。

目前 OceanBase 数据库 V4.x 的版本 RPC 框架没有检查接收端的连接长时间 hung 住的情况，如果连接出现异常可能无法被感知到。所以对应的 patch 给连接设置了有效的 TCP_USER_TIMEOUT，如果连接上发包异常能够尽快感知到并销毁重建连接，避免长时间频繁出现 OBServer inactive 的问题。

这个问题中导致某个连接 hung 住的根本原因目前还无法确定（目前怀疑是公有云环境的网络或者宿主机出现了异常），因为每次遇到后过了几个小时后 OBServer 还会恢复正常，没有留下现场。如果后续有再遇到的话并且现场还在的话，可以执行下面的命令，便于进一步定位 socket 异常 hung 住的根因。

在 RS 所在机器和出现 inactive 的机器上都执行 netstat 命令，需要隔几秒多执行几次，保留输出结果。

netstat -aen |grep observer 的 rpc_port > netstat.txt

问题的风险及影响

OBServer 短暂 inactive，可能会导致业务抖动。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本、V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP11 Hotfix7（oceanbase-4.2.1.11-111070032025081120）、V4.2.1 BP11 Hotfix8（oceanbase-4.2.1.11-111080012025082014）、V4.2.1 BP11 Hotfix9（oceanbase-4.2.1.11-111090012025091215）、V4.2.1 BP11 Hotfix10（oceanbase-4.2.1.11-111100012025092309）、V4.2.1 BP11 Hotfix11（oceanbase-4.2.1.11-111110012025101314）、V4.2.1 BP11 Hotfix12（oceanbase-4.2.1.11-111120022025110311）、V4.2.5 BP3（oceanbase-4.2.5.3-103000142025033110）、V4.3.5 BP1（oceanbase-4.3.5.1-101000292025030623）。

• 重启出现频繁 inactive 的 OBServer。

• 如果不希望重启的话，可以在出现 inactive 地节点上执行 tcpkill 命令强行杀掉对应的 RPC 连接（需要有 root 权限），示例如下。

  # eth0 是 OBServer 使用的网卡
  # 192.xxx.xxx.111 是 inactive OBServer 节点的 IP
  # 2882 是 111 的 inactive OBServer 节点的 RPC port
  
  tcpkill dst host 192.xxx.xxx.111 and port 2882
  
  # 执行了命令后需要尽快 ctrl c 退出
  

  注意

  因为 tcpkill 会一直运行并阻止主机 RPC 端口上的网络连接，所以执行 tcpkill 命令之后，需要尽快 ctrl c 退出。

规避方式

暂无。