线上某业务需要对日志信息入库并进行分析最后呈现在管理后台上。某天突然发现后台没有前一天的分析数据。首先认为是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包等，当然重要的需要单独保留。