MySQL:The last packet sent successfully to the server was 0 milliseconds ago.

这篇具有很好参考价值的文章主要介绍了MySQL:The last packet sent successfully to the server was 0 milliseconds ago.。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

出现异常”The last packet sent successfully to the server was 0 milliseconds ago.“的大部分原因是由于数据库回收了连接,而系统的缓冲池不知道,继续使用被回收的连接所致的

解决方法: 

(1)使用JDBC URL中使用autoReconnect属性

&autoReconnect=true&failOverReadOnly=false

(2) 修改MySQL的参数. /etc/my.cnf 添加 

将mysql回收空闲连接的时间变长,mysql默认回收时间是8小时,可以在mysql目录下的my.cnf中增加下面配置,将时间修改长一点

[mysqld]
wait_timeout=31536000
interactive_timeout=31536000

(3)重启mysql 

service mysql restart

原因分析: 
(1)大量数据访问情况下,mysql connection连接有可能失效 
(2)长时间不妨问,connection会失效 

也可以通过配置,让缓冲池去测试连接是否被回收,如果被回收,则不继续使用,以dbcp为例:文章来源地址https://www.toymoban.com/news/detail-777413.html

#SQL查询,用来验证从连接池取出的连接
dbcp.validationQuery=SELECT 1
#指明连接是否被空闲连接回收器(如果有)进行检验,如果检测失败,则连接将被从池中去除
dbcp.testWhileIdle=true
#在空闲连接回收器线程运行期间休眠的时间值,以毫秒为单位,一般比minEvictableIdleTimeMillis小
dbcp.timeBetweenEvictionRunsMillis=300000
#在每次空闲连接回收器线程(如果有)运行时检查的连接数量,最好和maxActive一致
dbcp.numTestsPerEvictionRun=50
#连接池中连接,在时间段内一直空闲,被逐出连接池的时间(1000*60*60),以毫秒为单位
dbcp.minEvictableIdleTimeMillis=3600000

到了这里,关于MySQL:The last packet sent successfully to the server was 0 milliseconds ago.的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包赞助服务器费用

相关文章

  • 已解决The last packet sent successfully to the server was 0 milliseconds ago. The driver has not receiv

    已解决The last packet sent successfully to the server was 0 milliseconds ago. The driver has not receiv

    注:此文章是在mysql8版本的前提下编写的。 在我们使用springcloud在连接mysql数据库时,有时会碰到如下这种异常: 为此我上网查了不少资料,在这里小总结一下: 1. 连接url是否正确(自己看看useSSL是否为false): 2.数据库服务是否打开: 找到MySql服务: 3.网上最多解决的等待

    2024年01月16日
    浏览(12)
  • mysql链接错误The last packet successfully received from the server was xxx milliseconds ago解决方案

    mysql链接错误The last packet successfully received from the server was xxx milliseconds ago解决方案

    线上项目偶尔出现错误,这个错误发现是在项目无人操作一段时间后就产生,如果有人操作,那就不会出现。 具体报错信息 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 385,290,819 milliseconds ago. The last packet sent successfully to the server was

    2024年02月03日
    浏览(9)
  • The plain HTTP request was sent to HTTPS port

    The plain HTTP request was sent to HTTPS port

    异常信息 原因 错误信息 “The plain HTTP request was sent to HTTPS port” 表明客户端尝试使用未加密的HTTP协议发送请求到一个配置为使用加密的HTTPS协议的端口。 解决方案 要解决这个问题,需要确保使用正确的协议和端口号进行请求。应该使用的HTTPS前缀。例如: 错误的请求: ht

    2024年04月14日
    浏览(8)
  • 解决The plain HTTP request was sent to HTTPS port

    现在越来越多的网站要求 http 访问转为更为安全的 https 访问,很多使用nginx部署的前端应用可以很方便的使用反向代理来实现,切换后,用http访问就会出现 \\\"The plain HTTP request was sent to HTTPS port\\\"的错误页面。 将此错误页面重定向到指定的https地址即可 假设端口号是8443: 另外,

    2024年02月11日
    浏览(11)
  • 400 The plain HTTP request was sent to HTTPS port

    400 The plain HTTP request was sent to HTTPS port

    接口请求发生问题: 解决方法: Nginx HTTP 服务器的报错 “ 400 Bad Request: The plain HTTP request was sent to HTTPS port ”,本文将讲解如何解决这个问题。 简单从报错的字面意思上来看,是因为HTTP请求被发送到HTTPS端口,这种报错多出现在Nginx既处理HTTP请求又处理HTTPS请求的情况。 以下

    2024年02月08日
    浏览(13)
  • ingress 400 Bad Request The plain HTTP request was sent to HTTPS port

    ingress 400 Bad Request The plain HTTP request was sent to HTTPS port

      问题现象         访问时返回400 Bad Request,并提示 The plain HTTP request was sent to HTTPS port 。 问题原因         Ingress Controller到后端Pod请求使用了默认的HTTP请求,但后端是HTTPS服务。。 解决方案         添加注释,让其使用https请求 官方配置:Annotations - NGINX Ingres

    2024年02月12日
    浏览(13)
  • k8s遇 The connection to the server :6443 was refused

    一般而言,6443端口是用于给apiserver使用的,如果报这个错误,就说明apiserver要么没起来,要么就是端口被占用了。 挨个检查以下几个守护进程有无问题,如果有报错日志,则需要进行排查 如果都没有问题,那就查看apiserver容器是否起来了 如果apisever没有正常运行中,就需要

    2024年01月19日
    浏览(12)
  • K8s ❉ The connection to the server 报错localhost:8080 was refused

    现象描述 K8s集群初始化成功后,kubectl get nodes 查看节点信息时报错: 报错信息: 解决办法: 执行以下命令

    2024年02月11日
    浏览(21)
  • K8s 重设解决 “The connection to the server xxx:6443 was refused” 问题

    K8s 重设解决 “The connection to the server xxx:6443 was refused” 问题

    有时 kubectl 执行命令时出现问题,无法连接 kube-apiserver,报错如下: 初步判断,kubelet 没有将 apiserver 拉起来。 上面报错说明 kubelet 没有正常启动。 日志如下: 注意,在生产环境谨慎执行,在测试环境可以考虑使用。注意,在 master 节点上操作。 这部分详细的可以参考 K8s

    2024年02月04日
    浏览(13)
  • 解决:The connection to the server raw.githubusercontent.com was refused - did you specify the right ho

    解决:The connection to the server raw.githubusercontent.com was refused - did you specify the right ho

    我在部署k8s集群安装fannel 时候 出现报错: The connection to the server raw.githubusercontent.com was refused - did you specify the right host or port? 原因:外网不可访问 解决办法: 在https://www.ipaddress.com/查询raw.githubusercontent.com的真实IP。 加入 再次运行 即可成功安装fannel 希望对各位有所帮助!

    2024年02月11日
    浏览(14)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包