【 使用环境 】生产环境
【 OB or 其他组件 】 obproxy
【 使用版本 】
【问题描述】
错误现象:
目前生产偶发报错: the last packet successfully received from the server was 425 milliseconds ago . the last packet sent successfully to the server was 425 milliseconds ago .
访问链路:
java程序(druid连接池) → obproxy → observer
初步原因:
obproxy->observer之间的连接断开了. 虽然druid连接池配置了探活, 并且obproxy返回链接可用,但是obproxy真正将请求发送到observer时发现链接失效了.
可能的解决办法:
druid有一个参数, druid.mysql.usePingMethod 决定是通过真正的sql (select 1) , 还是com_ping来探活. 设置成 druid.mysql.usePingMethod = false . 可以解决该问题?
疑问:
- obproxy收到druid的com_ping探活请求时, 会转发到Observer么? 还是自己就回复了 , 并不检查observer的真正链接情况
- 如果observer是一个集群. 即使配置 druid.mysql.usePingMethod = true + 验证sql为 select 1 . 收到druid的探活请求时, select 1 应该是按照路由策略发给某一个oberver 吧 ? 后续真正的sql 可能不落到这个observer ? 那么这个探活也并不能保证后面的操作链接一定没问题.
- obproxy → observer 也是连接池模型. 道理上 , obproxy在决定使用哪个observer后, 应该从对应的连接池拿到连接, 此时obproxy应该进行对应的探活吧? 也就是说 obproxy → observer 这一段链接的可用性由obproxy保证