线上某业务需要对日志信息入库并进行分析最后呈现在管理后台上。某天突然发现后台没有前一天的分析数据。首先认为是java程序问题,于是查看应用程序日志,发现数据缺失的那天应用程序日志也没有记录,很是奇怪。接着手动执行jar包,本想看屏幕输出的报错信息,结果程序刚启动运行,执行了3条入库的sql语句(insert)后便卡住不动了,反复尝试了2-3次都是这种情况,接着怀疑是远程的mysql数据库问题导致无法插入新数据。
连接到远程数据库上,首先查看磁盘的分区df-h,果然mysql所在的数据库分区(/data)磁盘空间使用率居然达到了100%,太吓人了。果断du-sch*/data定位到具体的目录下的大文件,发现均为mysql的binlog文件
每个文件均为1.1G,这是mysql数据库binlog的默认值
查看mysql错误日志,如下信息:
131019 3:00:12 [ERROR] /usr/local/mysql/bin/mysqld: Disk is full writing './mysql-bin.000261' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
131019 3:00:12 [ERROR] /usr/local/mysql/bin/mysqld: Retry in 60 secs. Message reprinted in 600 secs
131019 3:10:12 [ERROR] /usr/local/mysql/bin/mysqld: Retry in 60 secs. Message reprinted in 600 secs
基本可以断定是应用程序在insert新的数据时,由于磁盘空间不足导致无法写入binlog文件导致无法插入新数据。
情急之下先删除了部分binlog,后设置max_binlog_size=500M,文件被truncate了,然后重启mysql数据库,悲剧的事情发生了,数据无法正常启动,再次查看错误日志:
/usr/local/mysql/bin/mysqld: File './mysql-bin.index' not found (Errcode: 13)
有时出现这个错误是文件权限不正确导致,确定了mysql-bin.index文件的权限是没有问题的,属主和属组都是mysql
关闭mysqlbinlog的功能,在/etc/my.cnf中加入log-bin=0,数据库还是无法启动。
最后查看mysql-bin.index文件里的内容,描述的binlog文件都被删除了,问题就在这里。
只有重新初始化数据库,第一次没有指定datadir重启后出错:
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
再次初始化数据库,记得在/etc/my.cnf里把log-bin=0删除或者注释,因为需要开启binlog功能,连同binlog相关参数一起初始化,否则会报错。
/usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql --user=mysql --datadir=/data/mysql/core
再次重启终于,数据终于起来了,执行应用程序入库也正常了,将之前的测试数据清除,以免插入重复数据,最后执行应用程序入库。
以上为对一次案例的排错主要过程,期间还有一些小的经过,最终把问题解决。
总结:binlog是可以关闭的,但是很少有人这么做,可以通过showvariableslike'expire_logs_days'查看binlog的过期时间;setglobalexpire_logs_days=10设置binlog的过期时间,但是一般都是会对binlog定期删除,比如7天以上的打tar包,一个月以上的删除tar包等,当然重要的需要单独保留。