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

Question

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

(Spring) 应用程序在 Tomcat 中运行并使用具有以下设置的连接池：

    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 秒对于空闲连接来说已经很短了 window，因此我建议对您的池配置进行一些更改。

1.) 故意将 initialSize 和 minIdle（默认为 initialSize）设置得较低。这将使空闲连接数保持在较低水平。更少的空闲连接意味着在 60 年代 window 到期之前连接被重用的可能性更大。

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

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

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

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

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

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

connection issues with cleardb from cloudfoundry (on pivotal)

mysql

spring

cloud-foundry

cleardb