本文介绍连接异常相关问题的原因与解决方法。
事务提交非预期错误码导致连接断开
事务提交过程中，如果客户端返回的不是以下预期内的错误码，DB 端都会主动断开连接。
OB_SUCCESS OB_TRANS_KILLED OB_TRANS_CTX_NOT_EXIST OB_TRANS_TIMEOUT OB_TRANS_STMT_TIMEOUT OB_TRANS_NEED_ROLLBACK OB_TRANS_ROLLBACKED OB_NOT_MASTER OB_TRANS_IS_EXITING事务提交场景，DB 端断开连接场景的报错
-6225，transaction unknown。
业务报错
问题原因
上述事务 DB 端在提交过程中，由于网络环境问题， TCP 重传率比较高（最高到 50%），事务提交出现未决的情况（OB_TRANS_UNKNOWN,错误为 -6225），之后 DB 主动断开连接。客户端随后报 session interrupted 。 事务提交时客户端报 6225，表示的是一种未决情况，等同于事务提交超时，客户端不能认为已经提交失败或者成功，因此 DB 并非发生了数据的一致性问题。
解决方案
处理网络异常导致的事务提交超时问题。
获取连接超时（Get connection timeout）
业务报错信息
业务报错信息。
com.alipay.oceanbase.obproxy.druid.pool.GetConnectionTimeoutException: get connection timeout, maxWait=500ms, maxCount=10, currentCount=11
原因分析
客户端连接池被占满，导致新的请求无法从 druid 里面获取空闲连接。
解决方法
如果存在慢 SQL 问题，定位产生慢 SQL 的原因，如检查 DB 资源、网络、IO 是否存在问题。
如果不存在慢 SQL 问题，评估 DB 连接数水位情况，在连接数水位不高的情况下，按需调大应用的最大连接数。
通信链接失败（Communications link failure）
报错信息如下。
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 70,810 milliseconds ago. The last packet sent successfully to the server was 5,005 milliseconds ago.
原因分析
连接闲置时间超时：默认 8 小时（
interactive_timeout和wait_timeout的最小值），连接被 DB 踢掉。注意
如果客户端使用连接池的话，连接被 DB 踢掉的情况不是很常见。
客户端 SQL 执行耗时长：超过 JDBC 配置参数
sockettimeout，JDBC 会触发 Kill session 。
问题解决
连接闲置时间超时的问题，需增加客户端 ping 连接逻辑， DB 端一般不需要调整。
客户端 SQL 执行耗时长，优化慢 SQL 或根据情况调大
sockettimeout值。
Proxy 主动 kill session
Create Index 由于耗时较长，如果 30s 内没有返回结果，OBProxy 会主动 kill session，从而导致建索引失败。
PL 由于内部逻辑的不同，有可能 30s 没有数据返回，也可能出现 OBProxy 主动 kill session 。
原因分析
在 OBProxy V1.7.1 之前版本，发往 DB 端的所有语句，如果 ob_query_timeout + delta 内没有返回，则 OBProxy 主动 kill session。delta 可以配置，默认值为 20s 。
问题解决
升级 OBProxy V1.7.1 及以上版本，所有 DDL 语句不受
ob_query_timeout + delta超时时间的限制。升级至 OBProxy V1.7.5 及以上版本，PL 的超时分两种场景。
在事务中调用 PL，使用
ob_trx_timeout作为超时时间。事务外调用 PL，不受超时时间的控制。
适用版本
OBProxy V1.7.1 之前版本。OceanBase 数据库 V3.x 之前版本。
