共计 3960 个字符，预计需要花费 10 分钟才能阅读完成。
在 MySQL 的日常维护中，我们总会遇到这样或那样的问题，对于那些经常发生且有处理经验的事故，不论是新手还是老司机都能在故障规定的容错时间内解决。而对于那些不常见、比较棘手的问题，新手上路可能就显得举足无措了，这个时候新手和老司机的差距就体现出来了。从知识储备还是工作经验，可能老司机比新手强一点，但如果一个新司机没有日志排错的意识，不具备日志排错的经验，那怎么能学会弯道超车、漂移的快感。我们知道数据库中有很多重要的日志，如错误日志 error log、慢日志 slow log、二进制日志 binary log、查询日志 general log 等等其他日志，错误日志 error log 是我们分析问题参考的依据，它记录数据库的启动 / 运行 / 停止的过程，包含了 info、warning、error 三个级别，分析 error log 也有助于我们了解数据库的运行机制。
我们知道数据库中的 binary log、relay log 都是数据库本身自带的 purge 清理线程处理过时的没有用的日志，这种处理能有效释放磁盘空间。而对于慢日志 slow log、错误日志 error log 这种记录数据库实例整个运行阶段的日志，不会被定期处理，那么就有可能会被记录得过多，占据过多的磁盘空间。对于错误日志 error log，默认记录；对于 slow log 需要我们自己选择是否记录。建议开启 slow log 功能，这对于数据库优化之一的 SQL 优化有很大的帮助。
通常我们在业务主库是开启慢日志功能并通过参数 long_query_time 这个参数来控制执行时间多长的 SQL 被记录进慢日志中，且对于执行时间超过 1s 的 SQL 就认为是慢 SQL，这样的设定值，很多场合下不会记录太多的慢 SQL，因而不会占据太多的磁盘空间。然而当开发上线的程序有问题，SQL 执行效率不高，且执行的频率非常高，这些慢 SQL 被记录就会存在磁盘空间被撑爆的安全隐患，从而导致数据库宕机并尝试重启且多次尝试失败，严重影响业务。不过值得庆幸的是，该部分业务我们有 MMM 高可用架构，VIP 已经漂移到另一台 master 上了。
2018-05-29 09:09:18 28094 [ERROR] Error writing file ‘/opt/app/mysql/logs/slow.log’ (errno: 1 – No space left on device)
2018-05-29 09:09:18 28094 [ERROR] Error writing file ‘/opt/app/mysql/logs/slow.log’ (errno: 1 – No space left on device)
180529 09:09:19 mysqld_safe mysqld restarted
InnoDB: 3 transaction(s) which must be rolled back or cleaned up
InnoDB: Starting in background the rollback of uncommitted transactions
/opt/app/mysql/bin/mysqld: Error writing file ‘/opt/app/mysql/logs/slow.log’ (Errcode: 28 – No space left on device)
2018-05-29 09:09:33 33114 [ERROR] Could not open /opt/app/mysql/logs/slow.log for logging (error 28). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
2018-05-29 09:09:34 33114 [ERROR] /opt/app/mysql/bin/mysqld: Error writing file ‘/opt/app/mysql/tmp/mysqld.pid’ (Errcode: 28 – No space left on device)
2018-05-29 09:09:34 33114 [ERROR] Can’t start server: can’t create PID file: No space left on device
如上面的报错显示（只是选择截取部分错误日志），数据库发生错误的原因是磁盘没有足够的空间，慢日志无法写入，数据库尝试 restart 并 rollback 没有提交的事务（继续查看后面的日志能看到 redo log 的信息），而数据库也对我们提出了建议关闭错误日志的记录功能。继续看启动过程，发现关于 pid 文件的 No space left on device，数据库还是无法启动。排查故障并处理故障，在尽可能短的时间内恢复业务是最重要的，因而这里就没有详细的操作代码保存来说明。通过 df -Th 查看发现 / 空间不足，并 ls -lh 查看慢日志的大小是 1.2T，已经严重消耗了磁盘空间。这个时候我们并不能直接 rm -rf 删除慢日志文件，因为数据库的启动时需要慢日志功能切且日志文件占据了磁盘空间，我们只能重定向清空慢日志，这样数据库得以重新启动。
虽然我们的业务主库有 MMM 高可用架构，事实发现 VIP 确实是漂移到另一台 master 上，但仍然给我们的其他 slave 造成了复制同步错误的故障，更为严重的是影响到了我们的多源复制库的使用，内部人员使用和维护也带来很大的影响。对于数据库本身来讲，error log 和 slow log 不能自动清理，这有一定的优点，但同时也会有磁盘空间可能被撑爆的潜在危险。
如果能够通过一个 crontab，或者一个告警，定期或者提醒我们对慢日志进行清理，我想也不会造成如今的这个麻烦。我们可以通过如下的一个 Shell 脚本，策略是删除几天以前的慢日志，保留最近几天的慢日志，或者使用过 Inception 工具的，可以将慢日志定期拉走，备份到远端。
[root@172-16-3-190 shells]# cat clean_mysql_slow_log.sh
#!/binbash
#author=lyx
#time:2018-05-29
cur_date=`date +%y%m%d`
#step_days=5 #clean slowlog 6 days ago
for step_days in $(seq 5 -1 0)
do
end_date=`expr $cur_date – $step_days`
clean_line_num=`cat /opt/shells/slow.log |grep -n “^# Time: $end_date”|head -n 1|cut -d : -f 1`
if ((${#clean_line_num} > 1))
then
clean_max_line_num=`expr $clean_line_num – 1`
sed -i “1,$clean_max_line_num d” /opt/shells/slow.log
break
fi
done
echo $clean_max_line_num
echo $step_days
该脚本的策略是根据当前时间，保留最近 5 天的慢日志，每次运行脚本则保留的日志天数减少一天。当然如果你有更好的业务策略或者脚本逻辑也可以择优选择，比如你可以根据慢日志的文件大小，配置告警并触发清理，或者 crontab 都可以。
[root@172-16-3-190 shells]# bash clean_mysql_slow_log.sh
1746208
5
[root@172-16-3-190 shells]# bash clean_mysql_slow_log.sh
1638936
4
[root@172-16-3-190 shells]# cp /opt/app/mysql_3309/logs/slow.log .
cp: overwrite `./slow.log’? y
[root@172-16-3-190 shells]# ls -lh slow.log
-rw-r—– 1 root root 844M May 29 18:24 slow.log
[root@172-16-3-190 shells]# bash clean_mysql_slow_log.sh
1746208
5
[root@172-16-3-190 shells]# ls -lh slow.log
-rw-r—– 1 root root 781M May 29 18:25 slow.log
[root@172-16-3-190 shells]# bash clean_mysql_slow_log.sh
1638936
4
[root@172-16-3-190 shells]# cat slow.log |head -n 1
# Time: 180525 0:00:00
[root@172-16-3-190 shells]# bash clean_mysql_slow_log.sh
4257796
3
[root@172-16-3-190 shells]# ls -lh slow.log
-rw-r—– 1 root root 571M May 29 18:26 slow.log
[root@172-16-3-190 shells]# cat slow.log |head -n 1
# Time: 180526 0:00:01
其实这是一个比较 low 的一个技术点，但是慢日志的清理很容易被我们忽略，很多时候开发不会随意上线，DBA 也会对慢 SQL 进行把控并优化，然而当你半夜在睡觉，开发很晚上线一段有问题的代码，这个 时候的后果 ….，确实有些危险。慢日志功能是我们优化数据库的一个重要的参考，但也要注意慢日志文件的大小的增长速度，避免占据过多的磁盘空间。
：
