通信链路故障 - 从服务器成功接收的最后一个数据包是 [英] Communications link failure - last packet successfully received from the server was

查看:103
本文介绍了通信链路故障 - 从服务器成功接收的最后一个数据包是的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道之前已经问过这个问题并且有很多解决方案,但它们都没有对我有用,在我的情况下它有点不同。

I know this question has been asked before and there are plenty of solutions, but none of them worked for me and it is a bit different in my case.

我有一个服务器,其数据库通过隧道连接到其他服务器。运行ubuntu 1310和1204的服务器没有任何问题。但是使用相同的设置,相同的配置,相同的应用程序,我在1404上遇到此问题。

I have a server with a databases which tunneled to other servers. The servers that run ubuntu 1310 and 1204 don't have any issues. But with the same setup, the same configs, the same application, I get this issue on 1404.

服务器设置:

A - Ubuntu 1204 Server with MariaDB 10.0 Database
  B - Ubuntu 1204 Server with MariaDB 5.5 Client -> tunneled via autossh 14c and works perfect
  C - Ubuntu 1204 Server with MariaDB 5.5 Client -> tunneled via autossh 14c and works perfect
  D - Ubuntu 1310 Server with MariaDB 5.5 Client -> tunneled via autossh 14c and works perfect
  E - Ubuntu 1310 Server with MariaDB 5.5 Client -> tunneled via autossh 14c and works perfect
  F - Ubuntu 1310 Server with MariaDB 5.5 Client -> tunneled via autossh 14c and works perfect
  D - Ubuntu 1404 Server with MariaDB 5.5 Client (also tried mysql 5.5 and mariadb 10.0) -> tunneled via autossh 14c DOES NOT WORK though same setup and app:

2014-07-11 16:02:51 [SEVERE] com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 141 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.
2014-07-11 16:02:51 [SEVERE]    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
2014-07-11 16:02:51 [SEVERE]    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
2014-07-11 16:02:51 [SEVERE]    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2014-07-11 16:02:51 [SEVERE]    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.Util.handleNewInstance(Util.java:407)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1116)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3082)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2968)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3516)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1986)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2140)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:5022)
2014-07-11 16:02:51 [SEVERE]    at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
2014-07-11 16:02:51 [SEVERE]    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2014-07-11 16:02:51 [SEVERE]    at java.lang.reflect.Method.invoke(Method.java:606)
2014-07-11 16:02:51 [SEVERE]    at org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:126)
2014-07-11 16:02:51 [SEVERE]    at org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:109)
2014-07-11 16:02:51 [SEVERE]    at org.apache.tomcat.jdbc.pool.DisposableConnectionFacade.invoke(DisposableConnectionFacade.java:80)
2014-07-11 16:02:51 [SEVERE]    at com.sun.proxy.$Proxy76.setAutoCommit(Unknown Source)
2014-07-11 16:02:51 [SEVERE]    at me.botsko.prism.actionlibs.RecordingTask.insertActionsIntoDatabase(RecordingTask.java:174)
2014-07-11 16:02:51 [SEVERE]    at me.botsko.prism.actionlibs.RecordingTask.save(RecordingTask.java:35)
2014-07-11 16:02:51 [SEVERE]    at me.botsko.prism.actionlibs.RecordingTask.run(RecordingTask.java:332)
2014-07-11 16:02:51 [SEVERE]    at org.bukkit.craftbukkit.v1_6_R3.scheduler.CraftTask.run(CraftTask.java:58)
2014-07-11 16:02:51 [SEVERE]    at org.bukkit.craftbukkit.v1_6_R3.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:53)
2014-07-11 16:02:51 [SEVERE]    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
2014-07-11 16:02:51 [SEVERE]    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
2014-07-11 16:02:51 [SEVERE]    at java.lang.Thread.run(Thread.java:744)
2014-07-11 16:02:51 [SEVERE] Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2529)
2014-07-11 16:02:51 [SEVERE]    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2979)
2014-07-11 16:02:51 [SEVERE]    ... 21 more
2014-07-11 16:02:51 [INFO] [Prism]: Database connection error: Communications link failure

更多Stacktraces,始终是新应用程序会话的第一个例外(完全重启) https://gist.github.com/Slind14/ cd5a03ec289c30b1452e

More Stacktraces, always the first exception from a fresh application session (complete restart) https://gist.github.com/Slind14/cd5a03ec289c30b1452e

由于我找不到任何解决方案,我想知道你是否知道1310和1404之间可能导致这种情况发生的任何变化。

As I couldn't find any solution, I'm wondering if you are aware of any change between 1310 and 1404 that could cause this to happen.

+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 5        |
| deadlock_timeout_long       | 50000000 |
| deadlock_timeout_short      | 10000    |
| delayed_insert_timeout      | 300      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 50       |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| slave_net_timeout           | 3600     |
| thread_pool_idle_timeout    | 60       |
| wait_timeout                | 28800    |
+-----------------------------+----------+

更新:

当我保持远程数据库打开时一段时间我也得到MySQL服务器已经消失,再次只在1404服务器上。

when I keep the remote database open for a while I also get "MySQL server has gone away", again only on the 1404 servers.

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    38189
Current database: *** NONE ***


推荐答案

默认情况下,交互式会话显示变量显示 interactive_timeout 而不是 wait_timeout

By default in interactive session show variables shows interactive_timeout instead of wait_timeout

只需使用选项-e查看超时的实际值

Just use option -e for looking at real value of timeout

http://blog.mozilla.org/it/2012/04/24/ when-is-qwait_timeout-not-wait_timeout /

这篇关于通信链路故障 - 从服务器成功接收的最后一个数据包是的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆