MySQL日志故障的处理和分析

这是学习笔记的第 1796篇文章

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

问题的起因就是收到同事提醒，根据监控报警提示，磁盘空间满了。上面有一个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的慢日志，按照并发来看，这个值是很高的。所以在基本稳定了性能之后，慢日志的量级有了明显的变化。