连接诊断 - 数据库代理 V4.3.2 | OceanBase 文档中心

本文介绍当发生断连接时应该如何排查断连接产生的原因，以及如何解决对应断连接问题。

背景介绍

当前使用 ODP 时，请求执行的链路主要为：客户端发送请求到 ODP --> ODP 将请求路由到对应的 OBServer 节点 --> OBServer 节点处理请求发送回包给 ODP --> ODP 回包给客户端。目前整条链路上都可能发生断连接的场景，比如：请求处理时间较长导致客户端长时间没有收到回包而断开连接、用户登录信息填写错误的集群租户等导致无法登录、ODP 以及 OceanBase 数据库的内部错误导致断开连接等等。

当断连接发生的时候，最直接得到的信息是 OBServer 节点返回的错误包提示。您可以根据错误包的提示作初步的排查，但错误包提供的信息往往比较少，一般情况下很难确定问题，而且有一部分场景无法得到错误包提示，此时需要排查整条链路上的问题。ODP 针对这一问题，提供断连接的诊断信息记录。

诊断方法介绍

当发生断连接之后，ODP 会记录一段断连接日志到 obproxy_diagnosis.log 日志文件中，这里会详细记录断连接相关的信息，以租户名错误为例：

[2023-08-23 20:11:08.567425] [109316][Y0-00007F285BADB4E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798792, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"10.10.10.1:58218", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"test", user_name:"root", error_code:-4043, error_msg:"dummy entry is empty, please check if the tenant exists", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:""})

日志通用内容如下。

LOG_TIME：日志打印时间，即示例中的 2023-08-23 20:11:08.567425
TID：线程 ID，即示例中的 109316
TRACE_ID：trace_id，即示例中的 Y0-00007F285BADB4E0，可以通过 trace_id 与其他日志进行关联
CONNECTION：表示这条日志为连接诊断相关的日志
trace_type：诊断类型，目前诊断日志有以下几种类型，不同的诊断类型也对应不同的断连接问题
- LOGIN_TRACE：登录问题相关的诊断日志
- SERVER_INTERNAL_TRACE：OceanBase 数据库内部错误的诊断信息
- PROXY_INTERNAL_TRACE：ODP 内部错误导致断连接的诊断信息
- CLIENT_VC_TRACE：客户端主动断连的诊断日志
- SERVER_VC_TRACE：OceanBase 数据库主动断连的诊断日志
- TIMEOUT_TRACE：ODP 执行超时的诊断日志
CS_ID：ODP 内部标识客户端连接的 ID
SS_ID：ODP 内部标识 ODP 与 OceanBase 数据库之间连接的 ID
PROXY_SS_ID：由 ODP 生成的标识客户端连接的 ID，会传递给 OceanBase 数据库，可以用来筛选 OceanBase 数据库日志或者 sql_audit 表
SERVER_SS_ID：由 OceanBase 数据库生成的标识 ODP 与 OceanBase 数据库之间连接的 ID
CLIENT_ADDR：客户端的 IP 地址
SERVER_ADDR：出错或者断连接时对应的 OBServer 节点的地址
CLUSTER_NAME：集群名
TENANT_NAME：租户名
USER_NAME：用户名
ERROR_CODE：错误码
ERROR_MSG：错误信息，诊断断连接的关键内容
REQUEST_CMD：ODP 当前正在执行的 SQL 语句的类型，可能为内部请求的 SQL 语句类型
SQL_CMD：用户 SQL 语句的类型

除上述通用的信息外，诊断日志还包含额外诊断信息，具体内容由 trace_type 决定。

常见断连接场景

本节介绍几种常见的断连接场景，以及对应断连接场景的排查和解决方法。

登录断连接

登录断连接对应的 trace_type 为 LOGIN_TRACE，租户名错误导致断连接的诊断日志示例如下：

[2023-09-08 10:37:21.028960] [90663][Y0-00007F8EB76544E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"10.10.10.1:44018", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10018, error_msg:"fail to check observer version, empty result", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:"SELECT ob_version() AS cluster_version"})

额外诊断信息为 internal_sql，表示 ODP 当前执行的内部请求。

登录断连接产生的原因比较复杂，本文从用户操作和 OceanBase 数据库两个方面介绍产生原因和解决方法。

从用户操作方面来看，有如下几种场景会导致产生断连接：

场景	错误码	错误信息	解决方法
集群名错误	4669	cluster xxx does not exist	确保对应集群存在且集群名正确，可直连 OBServer 节点后执行 `show parameters like 'cluster';` 命令进行确认，输出中 `value` 值即为待连接的集群名。
租户名错误	4043	dummy entry is empty, please check if the tenant exists	确保对应的租户存在，可使用系统租户（root@sys）直连 OBServer 节点后执行 `SELECT * FROM DBA_OB_TENANTS;` 命令，查看集群中的所有租户。
ODP 白名单校验失败	8205	user xxx@xxx can not pass white list	通过管控台确认 ODP 白名单是否配置正确，详细操作可参见 OB Cloud 云数据库文档白名单分组。
OceanBase 数据库白名单校验失败	1227	Access denied	确认 OceanBase 数据库白名单是否配置正确，可通过查看 ob_tcp_invited_nodes 变量进行确认。
客户端连接数达上限	5059	too many sessions	可通过执行 `ALTER proxyconfig SET <var_name> = <var_value>;` 命令调整 ODP 的配置项 `client_max_connections` 做暂时的规避。
ODP 配置要求使用 SSL 协议，但是用户发起普通协议请求	8004	obproxy is configured to use ssl connection	修改 SSL 协议配置 `enable_client_ssl` 为不使用 SSL 协议连接（值为 false）；或者使用 SSL 协议访问。
直接访问 proxyro@sys	10021	user proxyro is rejected while proxyro_check on	不应直接使用 proxyro@sys 访问数据库。
云上用户在关闭 `enable_cloud_full_user_name` 的场景下使用三段式访问	10021	connection with cluster name and tenant name is rejected while cloud_full_user_name_check off	云上用户关闭 `enable_cloud_full_user_name` 时，ODP 会限制三段式的访问。您可开启 `enable_cloud_full_user_name` 配置，或者使用非三段式访问。
proxyro 密码配置错误	10018	fail to check observer version, proxyro@sys access denied, error resp { code:1045, msg:Access denied for user xxx }	默认情况下，proxyro 的密码不会存在问题的，如果手动更改过 OceanBase 数据库中 proxyro@sys 用户的密码，请确保 ODP 的配置项 `observer_sys_password` 值和 proxyro@sys 用户密码一致。
启动 ODP 时配置的 rootservice_list 不可用	10018	fail to check observer version, empty result	这里可以通过直连 OBServer 节点，通过 `SHOW PARAMETERS LIKE 'rootservice_list';` 命令查看 OceanBase 数据库的 Root Service，以确认 ODP 启动时配置的 server ip 是否可用。

从 OceanBase 数据库方面来看，有如下几种场景会导致产生断连接：

场景	错误码	错误信息	解决方法
集群信息查询为空	4669	cluster info is empty	直连 OceanBase 数据库，执行 internal_sql 字段的 SQL 语句确认 OceanBase 数据库返回的集群信息是否为空。
集群信息查询失败	10018	fail to check observer version fail to check cluster info fail to init server state	直连 OceanBase 数据库，执行 internal_sql 字段的 SQL 语句确认 OceanBase 数据库返回的集群信息是否为空。
Config Server 信息查询失败	10301	fail to fetch root server list from config server fail to fetch root server list from local	可以手动拉取启动时配置的 Config Server 的 URL（`obproxy_config_server_url` 的值），确认 Config Server 返回的信息是否正常。

超时断连接

超时断连接对应的 trace_type 为 TIMEOUT_TRACE，集群信息过期导致断连接的诊断日志示例如下：

[2023-08-17 17:10:46.834897] [119826][Y0-00007FBF120324E0] [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:7, proxy_session_id:7230691830869983235, server_session_id:3221504994, client_addr:"10.10.10.1:42468", server_addr:"10.10.10.1:21100", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10022, error_msg:"OBProxy inactivity timeout", request_cmd:"COM_SLEEP", sql_cmd:"COM_END"}{timeout:1, timeout_event:"CLIENT_DELETE_CLUSTER_RESOURCE", total_time(us):21736})

额外诊断信息有如下两条。

timeout_event：表示超时事件
total_time：表示请求执行时间

下表根据不同的超时事件介绍如何解决断连接问题。

超时事件	场景	错误码	相关配置	解决方法
CLIENT_DELETE_CLUSTER_RESOURCE	集群信息发生变化	10022	ODP 配置项 cluster_expire_time	可以通过执行 `ALTER proxyconfig SET <var_name> = <var_value>;` 命令调整 ODP 中 `cluster_expire_time` 配置项暂时规避，`cluster_expire_time` 配置项默认过期时间为一天，新的请求会重置过期时间。
CLIENT_INTERNAL_CMD_TIMEOUT	内部请求执行超时	10022	固定时间 30s	非预期超时，建议联系技术支持人员配合诊断。
CLIENT_CONNECT_TIMEOUT	客户端与 ODP 建连超时	10022	固定时间 10s	非预期超时，建议联系技术支持人员配合诊断。
CLIENT_NET_READ_TIMEOUT	ODP 等待用户请求数据超时	10022	OceanBase 数据库系统变量 net_read_timeout	修改系统变量 `net_read_timeout`，需注意修改 Global 级别的系统变量不会对已有连接生效。
CLIENT_NET_WRITE_TIMEOUT	ODP 等待回包数据超时	10022	OceanBase 数据库系统变量 net_write_timeout	修改系统变量 `net_write_timeout`，需注意修改 Global 级别的系统变量不会对已有连接生效。
CLIENT_WAIT_TIMEOUT	用户请求过程中，客户端连接长时间没有发生交互导致超时	10022	OceanBase 数据库系统变量 wait_timeout	修改系统变量 `wait_timeout` 暂时规避。
SERVER_QUERY_TIMEOUT	用户请求查询超时	10022	OceanBase 数据库系统变量 ob_query_timeout、hint 指定的 query_timeout	修改系统变量 `ob_query_timeout` 暂时规避。
SERVER_TRX_TIMEOUT	用户事务执行超时	10022	OceanBase 数据库系统变量 ob_trx_timeout	修改系统变量 `ob_trx_timeout` 暂时规避。
SERVER_WAIT_TIMEOUT	用户请求过程中，OceanBase 数据库连接长时间没有发生交互导致超时	10022	OceanBase 数据库系统变量 wait_timeout	修改系统变量 `wait_timeout` 暂时规避。

OceanBase 数据库主动断开连接

OceanBase 数据库主动断开连接对应的 trace_type 为 SERVER_VC_TRACE，ODP 与 OceanBase 数据库建连失败的诊断日志示例如下：

[2023-08-10 23:35:00.132805] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="SERVER_VC_TRACE", connection_diagnosis={cs_id:838860809, ss_id:0, proxy_session_id:7230691830869983240, server_session_id:0, client_addr:"10.10.10.1:45765", server_addr:"", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10013, error_msg:"Fail to build connection to observer", request_cmd:"COM_QUERY", sql_cmd:"COM_HANDSHAKE"}{vc_event:"unknown event", total_time(us):2952626, user_sql:"select 1 from dual"})

额外诊断信息有如下三条。

vc_event：表示断连接相关的时间，您无需太过关注
total_time：表示请求执行时间
user_sql：表示用户请求

OceanBase 数据库主动断连接有如下几种场景。

场景	错误码	错误信息	解决方法
ODP 与 OceanBase 数据库建连失败	10013	Fail to build connection to observer	需与 OceanBase 数据库配合诊断。
ODP 传输请求给 OceanBase 数据库时连接断开	10016	An EOS event eceived while proxy transferring request	需与 OceanBase 数据库配合诊断。
ODP 传输 OceanBase 数据库回包时连接断开	10014	An EOS event received while proxy reading response	需与 OceanBase 数据库配合诊断。

说明

OceanBase 数据库主动断连接的场景下，ODP 无法收集更为详细的信息，如果 ODP 配置的 OBServer 节点状态正常，则需要配合 OceanBase 数据库的日志进行诊断。

客户端主动断连接

客户端主动断连接对应的 trace_type 为 CLIENT_VC_TRACE，ODP 读请求时客户端断开连接的诊断日志示例如下：

[2023-08-10 23:28:24.699168] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="CLIENT_VC_TRACE", connection_diagnosis={cs_id:838860807, ss_id:26, proxy_session_id:7230691830869983239, server_session_id:3221698209, client_addr:"10.10.10.1:44701", server_addr:"10.10.10.1:21100", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10010, error_msg:"An EOS event received from client while obproxy reading request", request_cmd:"COM_SLEEP", sql_cmd:"COM_END"}{vc_event:"VC_EVENT_EOS", total_time(us):57637, user_sql:""})

额外诊断信息有如下三条。

vc_event：表示断连接相关的时间，您无需太过关注
total_time：表示请求执行时间
user_sql：表示用户请求

客户端主动断连接有如下几种场景。

场景	错误码	错误信息	解决方法
ODP 收发包时客户端发生断连接	10010	An EOS event received from client while obproxy reading request	需客户端配合诊断。
ODP 处理请求时客户端断连接	10011	An EOS event received from client while obproxy handling response	需客户端配合诊断。
ODP 回包时客户端发送断连接	10012	An EOS event received from client while obproxy transferring response	需客户端配合诊断。

说明

客户端断连接的场景下，ODP 无法收集更为详细的信息，只能指出客户端方面主动断开连接的操作。比较常见的断连接问题有驱动超时主动断开连接、Druid/Hikaricp/Nginx 等中间件主动断连接、网络抖动等问题，具体情况可与客户端配合诊断。

ODP 或 OceanBase 数据库内部错误

ODP 内部错误对应的 trace_type 为 PROXY_INTERNAL_TRACE，OceanBase 数据库内部错误对应的 trace_type 为 SERVER_INTERNAL_TRACE。ODP 内部错误的诊断日志示例如下：

[2023-08-10 23:26:12.558201] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="PROXY_INTERNAL_TRACE", connection_diagnosis={cs_id:838860805, ss_id:0, proxy_session_id:7230691830869983237, server_session_id:0, client_addr:"10.10.10.1:44379", server_addr:"", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10019, error_msg:"OBProxy reached the maximum number of retrying request", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{user_sql:"USE `ý<8f>ý<91>ý<92>`"})

额外诊断信息为 user_sql，表示用户请求 SQL。

ODP 或 OceanBase 数据库内部错误有如下几种场景。

诊断类型	场景	错误码	错误信息	解决方法
PROXY_INTERNAL_TRACE	租户分区信息查询失败	4664	dummy entry is empty, disconnect	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
PROXY_INTERNAL_TRACE	ODP 部分内部请求执行失败	10018	proxy execute internal request failed, received error resp, error_type: xxx	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
PROXY_INTERNAL_TRACE	ODP 重试请求达上限	10019	OBProxy reached the maximum number of retrying request	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
PROXY_INTERNAL_TRACE	ODP 目标 Session 被关闭	10001	target session is closed, disconnect	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
PROXY_INTERNAL_TRACE	其他未预期的错误场景	10001	诊断信息为空	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
SERVER_INTERNAL_TRACE	CheckSum 校验出错	10001	ora fatal error	未预期错误场景，您可联系技术支持人员协助排查或在开源官网问答区提问。
SERVER_INTERNAL_TRACE	主备库切换场景	10001	primary cluster switchover to standby, disconnect	主备库切换过程中可能存在的断连接问题，符合预期的场景。

其他场景

除上述场景外，诊断日志中还会存在如下两种符合预期的场景，对应的 trace_type 为 PROXY_INTERNAL_TRACE。

场景	错误码	错误信息	备注
kil 当前会话	5065	connection was killed by user self, cs_id: xxx	符合预期的场景，诊断日志作记录。
kill 其他会话	5065	connection was killed by user session xxx	符合预期的场景，诊断日志作记录。

诊断日志示例如下，额外诊断信息为 user_sql，表示用户请求 SQL。

[2023-08-10 23:27:15.107427] [32339][Y0-00007F74CAAE84E0] [CONNECTION](trace_type="PROXY_INTERNAL_TRACE", connection_diagnosis={cs_id:838860806, ss_id:21, proxy_session_id:7230691830869983238, server_session_id:3221695443, client_addr:"10.10.10.1:44536", server_addr:"10.10.10.1:21100", cluster_name:"undefined", tenant_name:"sys", user_name:"", error_code:-5065, error_msg:"connection was killed by user self, cs_id: 838860806", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{user_sql:"kill 838860806"})

示例

客户端请求到 OceanBase 数据库的链路比较常见的有下图两种。

链路图

客户端的请求到 OceanBase 数据库之间的链路需要经过多个节点，任一节点出现问题都有可能会导致客户端的连接断开。所以当发生断连接且客户端没有收到明确的错误包提示断连接原因时，排查断连接问题需先确定断连接方，之后再根据断连接方对应排查断连接原因。具体操作如下。

步骤一：确定断连接方

如果当前使用的 ODP 具备连接诊断能力，可通过诊断日志 obproxy_diagnosis.log 快速判断出现断连接问题的一方。您可根据用户名、租户名、集群名、从驱动中拿到的 thread_id（对应日志 cs_id）、断连接时间等信息从日志中快速筛选出对应的断连接日志，根据 trace_type 字段判断断连接方，trace_type 字段和断连接方的对应情况如下。

CLIENT_VC_TRACE：客户端断连接
SERVER_VC_TRACE：OceanBase 数据库主动断开连接
SERVER_INTERNAL_TRACE：OceanBase 数据库内部错误
PROXY_INTERNAL_TRACE：ODP 内部错误
LOGIN_TRACE：登录失败
TIMEOUT_TRACE：执行超时

步骤二：排查断连接原因

根据不同的断连接方，有如下几种不同的排查方法。

客户端断连接

JDBC 默认的 socketTimeout 配置为 0，即不会产生 socketTimeout 超时，但是部分客户端比如 Druid/MyBatis 自身有控制 socketTimeout 的参数，如果发生请求执行时间过长导致的断连接，可以优先确认 socketTimeout 的配置，详细信息可参见 OceanBase 数据库文档数据库连接池配置。

查看对应的 ODP 连接诊断日志，确定断连接的基本信息。

[2023-09-07 15:59:52.308553] [122701][Y0-00007F7071D194E0] [CONNECTION](trace_type="CLIENT_VC_TRACE", connection_diagnosis={cs_id:524328, ss_id:0, proxy_session_id:7230691833961840700, server_session_id:0, client_addr:"10.10.10.1:38877", server_addr:"10.10.10.2:50110", cluster_name:"ob1.changluo.cc.10.10.10.2", tenant_name:"mysql", user_name:"root", error_code:-10011, error_msg:"An unexpected connection event received from client while obproxy handling request", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{vc_event:"VC_EVENT_EOS", total_time(us):5016353, user_sql:"select sleep(20) from dual"})

主要诊断信息如下。

trace_type: 示例中诊断类型为 CLIENT_VC_TRACE，可判断出是客户端主动断开的连接。
error_msg : 示例中错误信息为 An unexpected connection event received from client while obproxy handling request，可判断出客户端在 ODP 处理请求时断开连接。
total_time: 示例中请求执行时间为 5016353，表示请求总的执行时间为 5s 左右，可以通过 total_time 去匹配客户端的超时参数。

根据 ODP 连接诊断日志信息确定是客户端主动断开了连接，从客户端入手排查，查看 JDBC 堆栈。

The last packet successfully received from the server was 5,016 milliseconds ago.  The last packet sent successfully to the server was 5,011 milliseconds ago.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1129)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3720)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4160)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2819)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2768)
        at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:949)
        at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:795)
        at odp.Main.main(Main.java:12)
Caused by: java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:170)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
        at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
        at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
        at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3163)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3620)
     9 more

从堆栈以及收发包时间可大致判断出示例中为 socketTimeout 触发的问题。

ODP 断连接

ODP 会读取 OceanBase 数据库设置的 net_write_timeout 配置，控制收包和发包时传包的超时时间，该配置默认时间为 60s。当网络环境比较极端或者 OceanBase 数据库回包处理较慢时，可能会出现 ODP 等待回包数据超时断连接的问题。此处以 ODP 等待回包数据超时场景为例介绍如何排查断连接原因。

根据 ODP 断连接诊断日志判断断连接方。

[2023-09-08 01:22:17.229436] [81506][Y0-00007F455197E4E0] [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={cs_id:1031798827, ss_id:342, proxy_session_id:7230691830869983244, server_session_id:3221753829, client_addr:"10.10.10.1:34901", server_addr:"10.10.10.1:21102", cluster_name:"undefined", tenant_name:"mysql", user_name:"root", error_code:-10022, error_msg:"OBProxy inactivity timeout", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{timeout(us):6000000, timeout_event:"CLIENT_NET_WRITE_TIMEOUT", total_time(us):31165295})

主要诊断信息如下。

trace_type: 示例中诊断类型为 TIMEOUT_TRACE，可判断出是因为 ODP 执行超时导致断连接。
timeout_event: 示例中超时事件为 CLIENT_NET_WRITE_TIMEOUT，可判断出 ODP 因为等待回包数据超时而发生断连接。

根据诊断信息可以确定触发了 net_write_timeout，客户端连接等待数据超过 6s（非默认值），导致连接断开，通过修改系统变量延长超时限制可暂时规避。

登录失败

此处以两种场景介绍如何排查断连接原因。

以 rootservice_list 指定的 OBServer 节点不可用为例介绍如何排查断连接原因，连接诊断日志如下。
```
[2023-09-08 10:37:21.028960] [90663][Y0-00007F8EB76544E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"10.10.10.1:44018", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10018, error_msg:"fail to check observer version, empty result", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:"SELECT ob_version() AS cluster_version"})
```
主要诊断信息如下。
- trace_type：示例中诊断类型为 LOGIN_TRACE，可确定是登录失败的问题。
- internal_sql：示例中 ODP 当前执行的内部请求为 SELECT ob_version() AS cluster_version，可确定登录过程中 ODP 执行该内部请求失败。
- error_msg：示例中错误信息为 fail to check observer version, empty result，可确定内部请求失败的原因为结果集为空。
诊断信息总结即为：ODP 执行内部请求 SELECT ob_version() AS cluster_version 失败，结果集为空。SELECT ob_version() AS cluster_version 这条 SQL 是 ODP 查询集群版本的请求，在您首次登录时 ODP 会执行这条请求校验集群信息，当 ODP 启动时配置的 rootservice_list 错误或者 OBServer 节点宕机时，ODP 查询失败，便会导致登录失败。

以客户端连接达到 ODP 上限为例介绍如何排查断连接原因。

客户端连接达到 ODP 上线导致断连接有如下两种排查方法。

方法一：排查连接诊断日志。

[2023-09-08 11:19:26.617385] [110562][Y0-00007FE1F06AC4E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798805, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"127.0.0.1:40004", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-5059, error_msg:"Too many sessions", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:""})

主要诊断信息如下。

trace_type：示例中诊断类型为 LOGIN_TRACE，可确定是登录失败的问题。
error_msg：示例中错误信息为 Too many session，可确定是因为连接数达到上限导致登录失败。

方法二：直接根据错误包判断，执行连接命令，输出 Too many sessions。

$ obclient -h127.0.0.1 -P2899 -uroot@sys -Dtest -A -c 
ERROR 1203 (42000): Too many sessions