--- title: 公有云 OBServer 节点频繁 inactive-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于公有云 OBServer 节点频繁 inactive相关的常见问题和使用技巧，帮助您快速解决公有云 OBServer 节点频繁 inactive的难题。 image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # 公有云 OBServer 节点频繁 inactive 更新时间：2026-06-04 09:56 适用版本： V4.2.x、V4.3.x 内容类型：Troubleshoot ## 问题现象 公有云环境出现 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 整数倍的有规律的值。 ![image01](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/20250228public-cloud-observer-nodes-frequently-inactive01.png) 此外，搜索 `PNIO rpc resp is expired` 也能匹配到大量 WDIAG 日志，并且日志中的 sock_id 都是同一个。 ![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/cluster-management/20250228public-cloud-observer-nodes-frequently-inactive02.png) 满足上述条件，就说明是遇到了这个问题。如果搜索 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 命令，需要隔几秒多执行几次，保留输出结果。 ```shell 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 权限），示例如下。 ```shell # 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` 退出。 ## 规避方式 暂无。 上一篇 [stop server 后 __all_server 的 status 字段仍然为 active 状态](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003867036) 下一篇 [rebuild_replica_data_lag_threshold 参数说明](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002949203) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线