新到了一家公司,这几天,开发三天两头反应执行mysql语句报1024的错误,经排查,是max_allowed_packet值过小导致的。于是乎调大该参数
命令行执行:
解决办法1.
mysql> set global max_allowed_packet = 2*1024*1024*10
但是过了一天,又反映报错。于是查看该参数
mysql> show variables like 'max_allowed_packet';+--------------------+----------+| Variable_name | Value |+--------------------+----------+| max_allowed_packet | 1024 |+--------------------+----------+1 row in set (0.00 sec)
奇怪了,这个参数又变回默认值了。
解决办法2.
怀疑mysql自动重启了。于是乎,设置mysql配置文件,添加一行参数
max_allowed_packet = 20M
重新命令行设置该参数
mysql> set global max_allowed_packet = 2*1024*1024*10
不出所料,下午的时候这个值又变成默认的了。。于是乎,各种百度。。。排除内存不够用问题,最后锁定在了mysql被人***,恶意设置。于是乎。
解决办法3.
开启mysql的全局日志
set global general_log=on;set global general_log_file='/tmp/general.log';
观察了一天,终于发现了端倪
发现有异常登录,恶意执行sql的纪录。于是。查看授权表
mysql> select User,Host,Password from mysql.user;+-----------+-----------+-------------------------------------------+| User | Host | Password |+-----------+-----------+-------------------------------------------+| root | localhost | *D10046E383955247E6D02EFC235FA9699FF1D663 || csd | % | *B404ADB7BC0DB0E0CD49F9D7EB9E8DAEB8FFA98C || zcdev | % | *B257B599CE4DE08F6043C8CA9062695084007E16 || pba | % | *C8E970FA54065F67198B1959007875A06E5F234E || lishibin | % | *88A194AD67780CF5B6350BE5766B43E82136506B || csef | % | *B2C53E908217DA3E4158AE24098116186CCF73B0 || csef_read | % | *A4E03156BBAB6BAD7433A764A3BAAE1C1B0785B8 || mysqld | % | *83D34C89B8E0F100D54C6D9276D357DB43E8779F || root | % | || root | % | *D10046E383955247E6D02EFC235FA9699FF1D663 || server | % | *866D5A029D62EC05ACC4584CE50F1CD2F50E0E82 || testmg | % | *5466FDB0B2316B196605A80D7CA89D34F999FB86 || mysqls | % | *7BE7CCD65B06F04379A48A396B3A0FF3D0194C22 |+-----------+-----------+-------------------------------------------+12 rows in set (0.00 sec)
然后问同事,他说执行这个root空密码登录已经改删除了,这里所有的账号都允许所有主机登录。极度不安全,于是。删除root空密码登录,更改root密码。并将所有账号的主机设置成内网登录。观察了2天,也没有***事件了。