自从上次出现了mysql has gone away 错误以后 ,有朋友回答是链接超时原因 引起的。 gateway 模型里 常驻内存运行的 连接 能否做一个机制 在底层 建立起的连接 每一定时间 向mysql服务 请求一次 以保持 连接不被断开呢? 我了解到 gateway 目前的方式 还是太被 动了,是等到请求时 发现已经报错 再连接一次 。这么做的话 后面的再连接一次 也不是太稳固。 我现在的gateway里 就还是出现了 gone away。
出现mysql gone away Gateway的 DbConnection会自动重连的,但是仍然会有一个warning,你可以重新更新下gateway框架,新版本屏蔽了这个waring。 定时ping并不能解决根本问题,连接还是有被断开的可能,最靠谱的就是目前的判断错误码重连的方案。
你的意思是 这个问题 可以忽略?实际已经重连了?我是2.0.1 版本
我查了一下 我的mysql com_kill value 为0 , uptime 数值也很高和开机时间一致 为什么会出现这个问题呢。现在就是这个不稳定 其它都挺好的
还有 其实定时ping 和 出错时重连不冲突 可以双管齐下 ,定时ping 间隔时间长 对资源消耗 可以忽略不计啊。 另外 ,到出错时的重连 排除硬性因素(比如mysql 服务宕机等) 在连接已经失效的情况下 重连 成功率高吗? 会不会再次连接不成功。这种情况怎么处理呢? 毕竟服务不容出差错啊。 关键时刻 取不到数据 这是致命的。
双管齐下有点多余了,如果开发者想要定时ping,加个定时器就好,非常简单。
在连接已经失效的情况下 重连 成功率高吗?
msyql关闭链接的时间一般是8小时,8小时只重连一次,效率问题完全可以忽略。另外8小时都没请求,这个业务也并不是繁忙业务,也不用考虑这点消耗。
会不会再次连接不成功。这种情况怎么处理呢?毕竟服务不容出差错啊。 关键时刻 取不到数据 这是致命的。
出现mysql gone away 后DbConnection只会重连一次,如果失败,就抛异常。业务可以捕获这个异常,然后根据数据重要情况自行决定如何处理。如果没捕获异常进程会退出重启一次。
出现mysql gone away Gateway的 DbConnection会自动重连的,但是仍然会有一个warning,你可以重新更新下gateway框架,新版本屏蔽了这个waring。
定时ping并不能解决根本问题,连接还是有被断开的可能,最靠谱的就是目前的判断错误码重连的方案。
你的意思是 这个问题 可以忽略?实际已经重连了?我是2.0.1 版本
我查了一下 我的mysql com_kill value 为0 , uptime 数值也很高和开机时间一致 为什么会出现这个问题呢。现在就是这个不稳定 其它都挺好的
还有 其实定时ping 和 出错时重连不冲突 可以双管齐下 ,定时ping 间隔时间长 对资源消耗 可以忽略不计啊。 另外 ,到出错时的重连 排除硬性因素(比如mysql 服务宕机等) 在连接已经失效的情况下 重连 成功率高吗? 会不会再次连接不成功。这种情况怎么处理呢? 毕竟服务不容出差错啊。 关键时刻 取不到数据 这是致命的。
双管齐下有点多余了,如果开发者想要定时ping,加个定时器就好,非常简单。
msyql关闭链接的时间一般是8小时,8小时只重连一次,效率问题完全可以忽略。另外8小时都没请求,这个业务也并不是繁忙业务,也不用考虑这点消耗。
出现mysql gone away 后DbConnection只会重连一次,如果失败,就抛异常。业务可以捕获这个异常,然后根据数据重要情况自行决定如何处理。如果没捕获异常进程会退出重启一次。