来自 cloudfoundry 的 cleardb 连接问题（关键）

Question

我们经常面临与 ClearDB 托管的 MySQL 的连接问题。我们有一个专门的计划，为我们的应用程序提供超过 300 多个连接。 我知道 ClearDB 站点上的 CBR 会在 60 秒后自动关闭非活动连接。

（Spring）应用程序在 Tomcat 中运行并使用具有以下设置的 ConnectionPool：

    org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
    dataSource.setDriverClassName("com.mysql.jdbc.Driver");
    dataSource.setUrl(serviceInfo.getJdbcUrl());
    dataSource.setUsername(serviceInfo.getUserName());
    dataSource.setPassword(serviceInfo.getPassword());
    dataSource.setInitialSize(10);
    dataSource.setMaxActive(30);
    dataSource.setMaxIdle(30);
    dataSource.setTimeBetweenEvictionRunsMillis(34000);
    dataSource.setMinEvictableIdleTimeMillis(55000);
    dataSource.setTestOnBorrow(true);
    dataSource.setTestWhileIdle(true);
    dataSource.setValidationInterval(34000);
    dataSource.setValidationQuery("SELECT 1");

我们在堆栈中看到的错误是：

 2015-01-13T13:36:22.75+0100 [App/0]   OUT The last packet successfully received from the server was 90,052 milliseconds ago.  The last packet sent successfully to the server was 90,051 milliseconds ago.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
 2015-01-13T13:36:22.75+0100 [App/0]   OUT The last packet successfully received from the server was 90,052 milliseconds ago.  The last packet sent successfully to the server was 90,051 milliseconds ago.

 2015-01-13T13:36:22.75+0100 [App/0]   OUT  ... 52 common frames omitted
 2015-01-13T13:36:22.75+0100 [App/0]   OUT Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
 2015-01-13T13:36:22.75+0100 [App/0]   OUT  at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2914) ~[mysql-connector-java-5.1.33.jar:5.1.33]
 2015-01-13T13:36:22.75+0100 [App/0]   OUT  at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3337) ~[mysql-connector-java-5.1.33.jar:5.1.33]
 2015-01-13T13:36:22.75+0100 [App/0]   OUT  ... 64 common frames omitted

您是否有任何想法可能导致这种情况，或者您是否在使用 ClearDB 时有类似的经历并且可能已经搬到其他地方？

很遗憾，我没有任何想法，非常感谢任何帮助。

Answer 1

您列出的错误看起来很像您的连接已在远程端断开（即通过 ClearDb）。 60 秒对于空闲连接来说是一个非常短的窗口，所以我建议您对池配置进行一些更改。

1.) 故意将 initialSize 和 minIdle（默认为 initialSize）设置为低。这将使空闲连接的数量保持在较低水平。更少的空闲连接意味着在 60 秒窗口到期之前，该连接更有可能被重用。

2.) 这里不需要 maxIdle。默认为 maxActive。

3.) 将 timeBetweenEvictionRunsMillis 设置得更低。这设置池检查空闲连接的频率。默认的 5s 应该没问题。

4.) 降低 minEvictableIdleTimeMillis。这是连接在被驱逐之前在池中的最短时间。但这并不意味着它会在它这么旧时被驱逐。如果空闲检查刚刚运行并且您的连接是 minEvictableIdleTimeMillis - 1s 旧，它将不得不等待下一次检查以驱逐连接（即 timeBetweenEvictionRunsMillis）。如果您使用 5 秒的默认 timeBetweenEvictionRunsMillis，将其设置为 50 秒应该会给它足够的时间。

5.) 将validationInterval 设置得较低。这决定了自上次成功验证后池在再次验证连接之前将等待多长时间。我会选择2到5秒之间的东西。它足够高，您可以在忙碌时获得一些好处，并且足够低，不会导致您在连接不良时错过验证。

6.) 我还建议您启用 removeAbandoned 和 logAbandoned，将 removeAbandonedTimeout 设置为 5 或 10 秒（大多数网络应用程序不应长时间保持数据库连接）。这将消除您的网络应用程序将连接保持在空闲状态超过 60 秒，然后再次尝试使用它的可能性。