Java自学者论坛

 找回密码
 立即注册

手机号码,快捷登录

恭喜Java自学者论坛(https://www.javazxz.com)已经为数万Java学习者服务超过8年了!积累会员资料超过10000G+
成为本站VIP会员,下载本站10000G+会员资源,会员资料板块,购买链接:点击进入购买VIP会员

JAVA高级面试进阶训练营视频教程

Java架构师系统进阶VIP课程

分布式高可用全栈开发微服务教程Go语言视频零基础入门到精通Java架构师3期(课件+源码)
Java开发全终端实战租房项目视频教程SpringBoot2.X入门到高级使用教程大数据培训第六期全套视频教程深度学习(CNN RNN GAN)算法原理Java亿级流量电商系统视频教程
互联网架构师视频教程年薪50万Spark2.0从入门到精通年薪50万!人工智能学习路线教程年薪50万大数据入门到精通学习路线年薪50万机器学习入门到精通教程
仿小米商城类app和小程序视频教程深度学习数据分析基础到实战最新黑马javaEE2.1就业课程从 0到JVM实战高手教程MySQL入门到精通教程
查看: 43219|回复: 0

mysql连接的空闲时间超过8小时后 MySQL自动断开该连接解决方案

[复制链接]
  • TA的每日心情
    奋斗
    2024-11-24 15:47
  • 签到天数: 804 天

    [LV.10]以坛为家III

    2053

    主题

    2111

    帖子

    72万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    726782
    发表于 2021-4-14 17:13:41 | 显示全部楼层 |阅读模式

    MySQL 的默认设置下,当一个连接的空闲时间超过8小时后,MySQL 就会断开该连接,而 c3p0 连接池则以为该被断开的连接依然有效。在这种情况下,如果客户端代码向 c3p0 连接池请求连接的话,连接池就会把已经失效的连接返回给客户端,客户端在使用该失效连接的时候即抛出异常

     

    解决这个问题的办法有三种:

    1. 增加 MySQL 的 wait_timeout 属性的值。

    修改 /etc/mysql/my.cnf文件,在 [mysqld] 节中设置:

    # Set a connection to wait 8hours in idle status.
    wait_timeout =86400
    相关参数,红色部分
    mysql> show variables like '%timeout%';
    +--------------------------+-------+
    | Variable_name        | Value |
    +--------------------------+-------+
    | connect_timeout     | 5       |
    | delayed_insert_timeout | 300 |
    | innodb_lock_wait_timeout | 50 |
    | interactive_timeout | 28800 |
    | net_read_timeout | 30 |
    | net_write_timeout | 60 |
    | slave_net_timeout | 3600 |
    | wait_timeout | 28800 |
    +--------------------------+-------+
    同一时间,这两个参数只有一个起作用。到底是哪个参数起作用,和用户连接时指定的连接参数相关,缺省情况下是使用wait_timeout。我建议是将这两个参数都修改,以免引起不必要的麻烦。

    这两个参数的默认值是8小时(60*60*8=28800)。我测试过将这两个参数改为0,结果出人意料,系统自动将这个值设置为。换句话说,不能将该值设置为永久。
    将这2个参数设置为24小时(60*60*24=604800)即可。
    set interactive_timeout=604800;
    set wait_timeout=604800;

    2. 减少连接池内连接的生存周期,使之小于上一项中所设置的 wait_timeout 的值。
    修改 c3p0 的配置文件,设置:

    # How long to keep unused connections around(in seconds)
    # Note: MySQL times out idle connections after 8hours(28,800seconds)
    # so ensure this value is below MySQL idle timeout
    cpool.maxIdleTime=25200
    在 Spring 的配置文件中:

      <bean id="dataSource"
      class="com.mchange.v2.c3p0.ComboPooledDataSource">
      <property name="maxIdleTime"value="${cpool.maxIdleTime}"/>
      <!--other properties -->
      </bean>

     

    3. 定期使用连接池内的连接,使得它们不会因为闲置超时而被 MySQL 断开。
    修改 c3p0 的配置文件,设置:

    # Prevent MySQL raise exception after a long idle timecpool.preferredTestQuery='SELECT 1'cpool.idleConnectionTestPeriod=18000cpool.testConnectionOnCheckout=true
    修改 Spring 的配置文件:

    <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
    <property name="preferredTestQuery" value="${cpool.preferredTestQuery}"/>
    <property name="idleConnectionTestPeriod" value="${cpool.idleConnectionTestPeriod}"/>
    <property name="testConnectionOnCheckout" value="${cpool.testConnectionOnCheckout}"/>
    <!--other properties --></bean>

    附:Mysql经典的“8小时问题”

    MySQL 的默认设置下,当一个连接的空闲时间超过8小时后,MySQL 就会断开该连接,而 c3p0 连接池则以为该被断开的连接依然有效。

    假设你的数据库是mysql,如果数据源配置不当,将可能发生经典的“8小时问题”。原因是mysql在默认情况下,如果发现一个连接的空闲时间超过8小时,将会在数据库端自动关闭这个连接。而数据源并不知道这个连接已经关闭了,当它将这个无用的连接返回给某个dao时,dao就会报无法获取connection异常。

        如果采用dbcp的默认配置,由于testOnBorrow属性的默认值是true,数据源在将连接交给dao前,会事先检测这个连接是否是好的,如果连接有问题(在数据库端被关闭),则会取一个其他的连接给dao。所以并不会有“8小时问题”。如果每次将连接交给dao时都检测连接的有效性,在高并发的应用中将会带来性能的问题,因为它会需要更多的数据库访问请求。

        一种推荐的高效的方式是:将testOnBorrow设置为false,而将“testWhileIdle”设置为true,再设置好testBetweenEvictionRunsMillis值(小于8小时)。那些被mysql关闭的连接就可以别清除出去,避免“8小时问题”。

        当然,mysql本身也能调整interactive-timeout(以秒为单位)配置参数,更改空闲连接的过期时间。所以,在设置timeBetweenEvictionRunsmMillis值时,必须首先获知mysql的空闲连接的最大过期时间。

        c3p0对于有效连接的检测,请参照dbcp配置方式。

    以上所述就是本文的全部内容了,希望大家能够喜欢。

    哎...今天够累的,签到来了1...
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|手机版|小黑屋|Java自学者论坛 ( 声明:本站文章及资料整理自互联网,用于Java自学者交流学习使用,对资料版权不负任何法律责任,若有侵权请及时联系客服屏蔽删除 )

    GMT+8, 2024-12-22 17:39 , Processed in 0.057780 second(s), 28 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表