MySQL 狂写错误日志

一台核心业务数据库,版本为MySQL 8.34 社区服务器版。从上线以来,这个数据库服务器的错误日志增增加非常迅猛(如下图所示),每24 小时能增加到10 多个G 的容量。

 

因为有故障报警,也还没有影响到业务的正常访问,有关人员不让重启MySQL 服务。鉴于这个情况,我只好设置一个自动计划任务,在每晚的夜间定点清理这些日志。具体的操作时候在系统命令行,执行“crontab -e” ,添加如下的文本行:

00 01 * * *    echo > /data/mysql8/data/mysql_db/mysql.log

保存并退出编辑模式,如果需要验证任务的正确性和有效性,可以把执行时间修改到相当近的一个时间点,然后对比任务执行前与执行后,错误日志文件“mysql.log ”的大小,同时查看cron 日志是否执行了这个计划任务,如下图所示。

 

春节放假,所有的人都回家过年,并且这个时候是访问低谷期,乘这个机会,我打算将这个问题彻底解决掉。征询相关人员的意见,问是否可以修改MySQL 选项文件,屏蔽掉没什么用的警告输出?得到的答复是“ 重启需要多久” ?答曰:“ 数分钟足够” 。

 

这个被定义的错误日志,大量记录的是什么东西呢?打开”mysql.log” 大文件,发现全是些警告信息,用系统命令“tail -f mysql.log” ,屏幕输出翻滚犹如电动机飞轮,具体的数据如下图所示。

这些警告信息表示用户账号使用了与默认认证方式“ caching_sha2_password” 不一致的“mysql_native_password” 。处理的方式要么将所有的用户账号的密码认证方式改成“ caching_sha2_password” ,要么错误日志文件“mysql.log” 不记录这些警告信息。由于用户账号比较多,设计到多个业务,相比之下,不记录警告信息更容易一些,反正这些警告信息没什么用(让它记录真正的错误日志,有助于排错)。

 

MySQL 服务器所在的宿主系统Centos 7, 文本编辑器打开选项文件“/etc/my.cnf” ,在文本块【mysqld 】里追加如下文本行。

log-error-verbosity=1

 

默认情况下,MySQL 8 的“log-error-verbosity” 的值为“3” ,表示在错误日志里记录所有的“ 错误、警告和注释” 。数字“2 ”代表记录“错误和警告”,而数字“1 ”则代表仅记录“错误”。

 

需要注意的是,在做选项文件修改前,记得先备份,这是常识,也是后悔药。检查没有书写错误以后,重启MySQL 服务,然后检查本地MySQL 服务是否正常,远程主从同步是否正常及是否存在延迟。

 

运行几分钟以后,再查看MySQL 的错误日志,是否不再迅猛增长。通过一段时间观察,确实不再记录MySQL 的警告日志,文件的增长速度也大大的降下来了。