在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开展把控并提升,殊不知如果你深夜在入睡,开发设计很夜里线一段有什么问题的编码,这一 情况下的不良影响....,的确一些风险。慢日志作用是大家提升数据库的一个关键的参照,但还要留意慢日志文档的尺寸的增速,防止占有过多的磁盘空间。