数据库的Packet for query is too large问题最终解决方案详解

最近数据库每隔几天,总是出现以下的问题:

这个问题,显示很明显就是max_allowd-packet的value值设置过小导致的。但是,当我第二次修改回来的时候,过了几天这个问题又会再次出现。一种莫名的忧伤袭来,不会是mysql的bug吧,我翻阅mysql的官网,并没有相关问题的bug及说明。
现在说一下,对这个参数的一些原理了解:
如果是在数据库启动的时候,未定义这个参数。系统会根据自己自身硬件及运行的情况,计算出一个初始值。当实际运行过程中,产生的packet缓存需求大于现行值,则向系统申请所需空间并同时,修改该参数现行值;如果系统内存资源耗竭,无法申请到所需空间时,此参数会舒适化一个默认的最小值1024!
但是,我发现系统的内存资源还很富裕,磁盘空间也是富裕的。嗯,是不是在某一时刻,有一个峰值,然后又还原了呢?查看历史监控,也并没有这个问题。
后来在stackoverflow看到了一个问题,提醒了我。虽然,很不愿意相信:Why mysql max_allowed_packet reset to 1m automatically
现在说一下处理办法:
show global VARIABLES like '%max_allowed_packet%'; (注意:mysql 系统参数分为session和global 之分, session只当前连接生效,global 全局连接生效)
1).通过mysql客户端,set global max_allowed_packet = 16*1024*1024*10; (修改后,重启数据库会恢复为默认)
2).修改my.cnf 在[mysqld]段或者mysql的server配置段进行修改。(终极修改, 修改后重启数据库,永久生效)
如下: max_allowed_packet = 16M
然后,我把generl.log打开,

再次出现异常时,查看查看general_log:
generl.log问题
好了,问题已经找到。是N多年前,这个机器做了一个外网的映射,导致了这个问题。好的,关闭映射。

总结:
1. 再次证明在遇到复杂技术问题google 比百度要靠谱多
2. 日志分析是解决问题的必须途径
3. 增加信息安全意识,原来黑客离我们并不远,如果不是故意暴露自己,我们也不会发现此机器被黑,黑客控制此机器后,可以轻易使用此机器,进行相关非法活动
具体:
1. 外网机器,一定要开启防火墙,只开放提供服务端口,禁用其它端口。 制定相关安全策略,如记录登陆用户ip,定期查看登陆用户历史及登陆失败记录,对于反复登陆能拒绝登陆。
2. 系统用户名,应该根据需要确定是否使用root用户,具体业务最好使用普通用户权限。因为root用户,拥有系统系统的全部权限。
3.密码:强密码策咯,并且能够定期更换最好。
4. 数据安全:
mysql应该给不同业务创建不同用户,并赋予有限功能权限,禁止root 用户做业务操作

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: