使用obproxy连接创建租户时报错(conn=173695) unexpected end of stream, read 0 bytes from 4

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】社区版4.3.5.2
【问题描述】使用obproxy连接时创建租户报错(conn=173695) unexpected end of stream, read 0 bytes from 4

1 个赞
#3

看起来是请求到了后端报错，检查下observer和obporxy的进程和服务是否正常。

1 个赞
#4
  1. 需要observer创建 obproxyro 用户，账号密码 也需要一致， 您核查下
  2. odp也有个内部配置密码参数
    alter proxyconfig set observer_sys_password = ‘aaAA11__’
    您把报错连接的 截图 发一下吧。
#6

连接可以正常连接，但是在执行新建租户的时候会报错，怀疑是时间设置的问题，耗时较长的sql会报错。目前直连建租户没有这个问题。

#7

odp 和observer 不在 同一台 物理机上吗 ？？

设置 ob_query_timeout 特别大试一试。 单位似乎是us

#8

大概率是超时断链，ob_query_timeout超时时间是多少调大点。
conn=173695这个是cs_id，可以根据该id去grep一下obproxy_diagnosis.log日志

#9

在同一台物理机上面，我试了一下，目前超过5s就会报错。

image
image2020×1204 104 KB

#10

黑屏使用2881端口连接测试下超时时间看看

#11

image
image1190×571 68.8 KB

2881端口没问题 2883存在问题

#12

那应该是JDBC那边设置的超时导致的。查询下看看

#13

是要查询 obproxy 的 jdbc 设置吗，这个具体是在哪查询呢

#14

@论坛小助手

#15

根据文档库中的信息，您可以从以下几个方面排查和解决 OBProxy 的 JDBC 超时问题：

1. 检查 JDBC 连接参数

  • 确认您的 JDBC URL 中是否设置了超时参数。例如：
    jdbc:mysql://10.1.0.0:2883/unittests?user=root@sys&password=******&socketTimeout=0&connectTimeout=30000
    • socketTimeout: 定义了网络 Socket 超时时间（毫秒）。值为 0 表示没有超时限制。
    • connectTimeout: 定义了连接超时时间（毫秒）。默认值为 30000 毫秒（30 秒）。

参考文档：《数据库连接池配置 → JDBC 配置参数》

2. 检查 OBProxy 的超时设置

  • OBProxy 可能因为 net_write_timeout 或其他超时参数导致断连。您可以通过以下方式检查和调整：
    • 查询当前的 net_write_timeout 设置：
      SHOW VARIABLES LIKE 'net_write_timeout';
    • 如果需要调整该参数，可以执行以下命令（单位为秒）：
      SET GLOBAL net_write_timeout = 120;

参考文档：《ODP 端故障 → 应急处理步骤》

3. 检查 SQL 级别的超时设置

  • 如果您怀疑是 SQL 执行时间过长导致的问题，可以尝试在 SQL 级别添加 Hint 来设置超时时间。例如：
    SELECT /*+query_timeout(100000000) */ sleep(8);
  • 或者全局设置 ob_query_timeout 参数：
    SET GLOBAL ob_query_timeout = 100000000; -- 单位为微秒

参考文档：《关于超时时间 → 设置超时时间》

4. 检查 OBProxy 日志

  • 如果问题仍然存在，建议检查 OBProxy 的诊断日志 (obproxy_diagnosis.log)，定位具体的超时原因。例如：
    grep "cs_id:173695" /path/to/obproxy_diagnosis.log
  • 日志中可能会包含类似以下的信息：
    [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={... error_msg:"OBProxy inactivity timeout" ...})

参考文档：《obproxy_diagnosis.log 中连接类型的日志》

5. 确认 JDBC 驱动版本

  • 确保使用的 JDBC 驱动版本与 OceanBase 数据库版本兼容。如果驱动版本过旧，可能会导致一些超时问题。

总结

通过以上步骤，您可以逐步排查 JDBC 超时问题。如果问题仍未解决，建议联系 OceanBase 的技术支持团队以获取进一步帮助。

详情请参考:

  1. 数据库连接池配置
  2. 连接诊断
  3. OBProxy 性能监控
  4. ODP 端故障
  5. 在您开始前
  6. Show Trace
  7. connection_control_max_connection_delay
  8. 使用 OBLOADER 旁路导入数据
  9. obproxy_diagnosis.log
#16

这个配置在图中这个应用程序里面

image
image2020×1204 110 KB

#17

这些我都试过了，现在是通过obclient 来连接 2883 端口，在执行一些sql的时候也会报错。

image
image1532×307 169 KB

#18

[2025-06-11 17:17:18.622367] [98413][Y0-00007FC67290F5E0] [CONNECTION]([CONNECTION](trace_type=“SERVER_VC_TRACE”, connection_diagnosis={cs_id:1572984, ss_id:0, proxy_session_id:13882479996272050558, server_session_id:3221562182, client_addr:“192.168.12.178:34888”, server_addr:“192.168.12.205:2881”, proxy_server_addr:“192.168.12.205:59656”, cluster_name:“obdemo”, tenant_name:“sys”, user_name:“root”, error_code:-10014, error_msg:“An unexpected connection event received while proxy reading response”, request_cmd:“OB_MYSQL_COM_QUERY”, sql_cmd:“OB_MYSQL_COM_QUERY”, req_total_time(us):11109}{vc_event:“VC_EVENT_DETECT_SERVER_DEAD”, user_sql:"/NDTM/ SELECT OBJECT_TYPE %2C OBJECT_NAME %2C CASE WHEN VARIABLE_NAME = ‘trans local trans count’ THEN ‘trans single partition count’ WHEN VARIABLE_NAME = ‘trans distribute trans count’ THEN ‘trans multi partition count’ ELSE VARIABLE_NAME END AS VARIABLE_NAME%2C VARIABLE_VALUE FROM ( SELECT ‘CLUSTER’ AS OBJECT_TYPE%2C ‘-’ AS OBJECT_NAME%2C NAME AS VARIABLE_NAME%2C SUM(VALUE) AS VARIABLE_VALUE FROM OCEANBASE.GV$SYSSTAT WHERE STAT_ID IN (10000%2C 10001%2C 10002%2C 10003%2C 10005%2C 10006%2C 20000%2C 20001%2C 20002%2C 30000%2C 30001%2C 30002%2C 30005%2C 30006%2C 30007%2C 30008%2C 30009%2C 30010%2C 30012%2C 30013%2C 40000%2C 40001%2C 40002%2C 40003%2C 40004%2C 40005%2C 40006%2C 40007%2C 40008%2C 40009%2C 40013%2C 40010%2C 40011%2C 40012%2C 40018%2C 40019%2C 40030%2C 50000%2C 50001%2C 50004%2C 50005%2C 60000%2C 60001%2C 60002%2C 60003%2C 60004%2C 60005%2C 60022%2C 60023%2C 50008%2C 50009%2C 50010%2C 50011%2C 50037%2C 50038%2C 80040%2C 80041%2C 80057%2C 120000%2C 120001%2C 120006%2C 120008%2C 120009%2C 130000"})

#19

这个全局变量调大点试试
SET GLOBAL ob_query_timeout = 1000000000000;

#20

[2025-06-11 17:17:18.622367] [98413][Y0-00007FC67290F5E0] [CONNECTION]([CONNECTION]
这个报错需要在提供一下observer相关日志。应该是ob侧断开的，根据下面的方法提取下ob日志
1）设置trace信息
SET ob_enable_show_trace=‘ON’;

2）执行sql。

3）获取上个命令的trace
select last_trace_id();

4）获取trace对应的节点
select query_sql,svr_ip from gv$ob_sql_audit where trace_id=‘第三步获取的trace信息’；

5）取对应的svr_ip节点 过滤日志
grep “第三步获取的trace信息” observer.log*
grep “第三步获取的trace信息” rootservice.log*

6）提供日志信息即可。