ITPub博客

首页 > 数据库 > MySQL > 开启mysql审计后引发的问题

开启mysql审计后引发的问题

MySQL 作者:wzq609 时间:2015-09-02 11:30:35 0 删除 编辑

【前言】刚在mysql的测试环境中开启了审计的功能,结果第二天业务人员就反馈测试库登录不。幸好是测试环境,不然就惨了。。。。。

 

详细报错如下:

mysql> insert into test.test values (4);
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    76571
Current database: *** NONE ***

 

数据库的日志信息:

7:30:22 [Warning] Aborted connection 76570 to db: 'unconnected' user: 'ipos' host: '192.168.1.20' (init_connect command failed)
7:30:22 [Warning] Duplicate entry '6' for key 'PRIMARY'
7:30:22 [Warning] Aborted connection 76571 to db: 'unconnected' user: 'ipos' host: '192.168.1.15' (init_connect command failed)
7:30:22 [Warning] Duplicate entry '76571' for key 'PRIMARY'
7:30:22 [Warning] Aborted connection 76572 to db: 'unconnected' user: 'ipos' host: '192.168.1.14' (init_connect command failed)
7:30:22 [Warning] Duplicate entry '76572' for key 'PRIMARY'
7:30:24 [Warning] Aborted connection 76573 to db: 'unconnected' user: 'ipos' host: '192.168.1.20' (init_connect command failed)
7:30:22 [Warning] Duplicate entry '76572' for key 'PRIMARY'

 

原因分析:

init-connect存放数据的表脚本如下:

CREATE TABLE logDB.log (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))

 

因为此处的id值取自processlist的id值;

image 

当数据库不重启的情况下,这个ID值是一直增加的;但是当数据库重新启动之后,processlist显示每个用户的ID值又会从1开始,而如果是这样的话,那么插入到表logDB.log里面的id值便违反了创建的规则;所以就报错了。

 

显示这个数据库每天晚上22点30分都会定时自动重启,符合了问题的场景;

image

 

【解决方法】

1、很明显可以把创建表中id值的primary key 取消掉,但是这样在查找问题的时候可能就会在logDB.log中找到多条记录,通过对时间进行筛选的话,也是可以判断出问题的原因;

2、这是一个比较笨的方法,就是尽量不重启,如果重启的话就把表logDB.log的记录清空一遍;

希望看到前面那篇文档的朋友能够看到这篇,避免这种问题发生在生产系统上面;

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/12679300/viewspace-1789267/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-06-16

  • 博文量
    173
  • 访问量
    3083836