MySQL日志故障的处理和分析

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MySQL日志故障的处理和分析，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6887字，纯文字阅读大概需要10分钟。

内容图文

有一台预上线的服务器最近在做压力测试，也引发了一系列的相关问题，排查思路可以提供参考。

问题的起因就是收到同事提醒，根据监控报警提示，磁盘空间满了。上面有一个MySQL服务，现在已经写入不了数据了。

>create table test(id int);
ERROR 14 (HY000): Can‘t change size of file (Errcode: 28 - No space left on device)

碰到这类问题，直观的思路就是查看分区下最大的文件，当然如果足够智能，也可以启用前几天提到的故障自愈的实现思路。

当我切换到日志目录的时候，我发现慢日志文件竟然有这么大，都是百G级别。

-rw-r----- 1 mysql mysql 302365433856 Nov 7 07:55 slowquery.log
当时也是为了尽快的释放慢日志文件的空间，所以先是选择了导出部分日志到本地，作为后续的分析所用，然后清理了这个日志文件。

系统层面是清理了文件，空间也可以通过du的方式看到是释放了，但是使用df -h的方式却不奏效，看起来是文件的句柄没有正确释放，在这种情况下，系统虽然释放了不少的空间，但是数据库层面还是写入不了数据的。

这种情况该怎么做，释放句柄最好的一种方式就是重启，但是显然这不是一个好的方法，有些简单暴力，有没有更好的方案呢，我们来看看满日志相关的参数。

show variables like ‘%slow%‘;
+-----------------------------------+------------------------------------+
| Variable_name | Value |
+-----------------------------------+------------------------------------+
| log_slow_admin_statements | OFF |
| log_slow_filter | |
| log_slow_rate_limit | 1 |
| log_slow_rate_type | session |
| log_slow_slave_statements | OFF |
| log_slow_sp_statements | ON |
| log_slow_verbosity | |
| max_slowlog_files | 0 |
| max_slowlog_size | 0 |
| slow_launch_time | 2 |
| slow_query_log | OFF |
| slow_query_log_always_write_time | 10.000000 |
| slow_query_log_file | /data/mysql_4350/log/slowquery.log |
| slow_query_log_use_global_control | |
+-----------------------------------+------------------------------------+
这里我们可用的一个直接方式就是先关闭满日志，达到释放句柄的目的，然后再次重启开启。

想明白了，操作就很简单了。

set global slow_query_log=off;
Query OK, 0 rows affected (6.54 sec)

set global slow_query_log=on;
Query OK, 0 rows affected (0.00 sec)
很明显，磁盘空间释放了不少，对于慢日志的问题分析，其中里面有一个数据字典表存在大量的查询请求，添加了索引之后，该问题得到了有效控制。

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda3 25G 5.5G 18G 24% /
tmpfs 31G 12K 31G 1% /dev/shm
/dev/sda1 190M 78M 103M 44% /boot
/dev/mapper/data-main
717G 400G 281G 59% /data
这个问题刚过一会，又收到报警说磁盘空间又满了，这次排除了慢日志的影响，发现是审计日志出了问题。

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 25G 5.5G 18G 24% /
tmpfs 31G 12K 31G 1% /dev/shm
/dev/sda1 190M 78M 103M 44% /boot
/dev/mapper/data-main
717G 609G 72G 90% /data
这里需要说明的是，审计插件有几类比较流行的，这里用到的是Percona audit plugin,其实从性价比来说，这个插件的控制粒度还算比较粗，如果从控制的粒度来说，MariaDB Audit plugin要好很多，推荐使用。

审计日志有差不多600G,在这种高压测试之下，量级还是很大的，为了缓解问题，也是删除了600G的审计日志文件。

打开审计日志的参数选项：

show variables like ‘%audit%‘;
+-----------------------------+---------------+
| Variable_name | Value |
+-----------------------------+---------------+
| audit_log_buffer_size | 1048576 |
| audit_log_exclude_accounts | |
| audit_log_exclude_commands | |
| audit_log_exclude_databases | |
| audit_log_file | audit.log |
| audit_log_flush | OFF |
| audit_log_format | OLD |
| audit_log_handler | FILE |
| audit_log_include_accounts | |
| audit_log_include_commands | |
| audit_log_include_databases | |
| audit_log_policy | ALL |
| audit_log_rotate_on_size | 0 |
| audit_log_rotations | 0 |
| audit_log_strategy | ASYNCHRONOUS |
| audit_log_syslog_facility | LOG_USER |
| audit_log_syslog_ident | percona-audit |
| audit_log_syslog_priority | LOG_INFO |
+-----------------------------+---------------+
18 rows in set (0.01 sec)
这里可以选的方式是修改审计日志的策略，比如我们从ALL修改为NONE,但是这种方式还是有些局限，因为没有生效。到了这个时候可供选择的方案就很少了，如果要释放句柄，我们可以简单先看看，比如通过lsof来查看未释放的句柄。

lsof|grep delete

mysqld 3218 mysql 5u REG 253,0 26946 85458954 /data/mysql_4350/tmp/ib6i5l8w (deleted)
mysqld 3218 mysql 6u REG 253,0 0 85458955 /data/mysql_4350/tmp/ibzgbLJz (deleted)
mysqld 3218 mysql 7u REG 253,0 0 85458956 /data/mysql_4350/tmp/ibUZDalC (deleted)
mysqld 3218 mysql 8u REG 253,0 0 85458960 /data/mysql_4350/tmp/ibhdSF1K (deleted)
mysqld 3218 mysql 12u REG 253,0 0 85458961 /data/mysql_4350/tmp/ibo46oDR (deleted)
mysqld 3218 mysql 41w REG 253,0 635612876075 85460307 /data/mysql_4350/data/audit.log (deleted)
但是很明显这个进程就是MySQL服务的进程号，直接kill MySQL实在是太暴力了，而且这个测试还在进行中，为了避免不必要的解释和麻烦，我们也是不能重启数据库的。

ps -ef|grep 3218

mysql 3218 2015 22 Oct31 ? 1-14:53:02 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql_4350/data --plugin-dir=/usr/local/mysql/lib/mysql/plugin --user=mysql --log-error=/data/mysql_4350/log/mysql.err --open-files-limit=16384 --pid-file=/data/mysql_4350/tmp/mysql.pid --socket=/data/mysql_4350/tmp/mysql.sock --port=4350
root 87186 86999 0 15:20 pts/0 00:00:00 grep 3218
这里有一个参数引起了我的注意，那就是audit_log_flush，有点类似于MySQL里面的flush logs的方式。通过触发这个参数就可以释放已有的句柄了。

set global audit_log_flush=on;
Query OK, 0 rows affected (10.04 sec)
通过几轮问题分析和排查，日志类的问题总算得到了基本解决。

后续需要改进的就是对于审计日志的管理，目前做压力测试其实是可以关闭这一类的审计的。

而对于慢日志的分析也是重中之重，如果在极高的压力下，差不多1~2分钟会产生1G的慢日志，按照并发来看，这个值是很高的。所以在基本稳定了性能之后，慢日志的量级有了明显的变化。

MySQL日志故障的处理和分析

标签：slowlog   日志   change   socket   set   plugin   admin   test   这一   

本文系统来源：http://blog.51cto.com/14028890/2314778

内容总结

以上是互联网集市为您收集整理的MySQL日志故障的处理和分析全部内容，希望文章能够帮你解决MySQL日志故障的处理和分析所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---