标题:mysql “log-bin”引起的linux空间不足 【转】 出处:沧海一粟 时间:Thu, 24 Jun 2010 06:38:37 +0000 作者:jed 地址:http://www.dzhope.com/post/665/ 内容: 这两天在做数据的汇总与统计,统计去年12月份到现在的数据,数据全部以小时暂存到了文件里面,每个文件都有几百兆,算起来每个文件有接近十万条记录,程序做了两天周一回来发现只做了十几个文件,这些速度太慢了。然后想到,把表升级到内存表来做汇总。汇总完以后分类存到硬盘。这样看起来速度快了,很多… 但是今天早上起来本来想着肯定是要处理了几十个,结果来了一看,杯具了:数据库提示提示硬盘满了! LOG: Insert flow error: Disk is full writing ‘./mysql-bin.000127′ (Errcode: 28). Waiting for someone to free space… (Expect up to 60 secs delay for server to continue after freeing disk space) discuz论坛js无法更新,附件无法上传。 有220G的硬盘怎么就满了呢?是数据文件太多了? 查看了下,发现home 占用了接近80G 空间。 [root@localhost ~]# du -h –max-depth=1 /home 78G /home 那么文件会是跑到哪里去了呢? 一个邪恶的念头突然蹦出来了:不是服务器被攻击了吧?黑客用我们做了文件服务器?那样可就惨了… 一个一个查,最后定位到了/var/lib/mysql/下,哦!突然想起来了,是不是数据库太大了,文件太多了?数据库记录是比较多,但是也不至于有120G吧?百度一下,网上说了,mysql数据库记录输入删 掉以后,MySQL没有自动释放硬盘空间,而是自己管理已经向操作系统申请的空间,可以通过optimize table语法或alter table TableName engine=****来实现空间的释放。 当表的记录被删除时,数据文件并不会即时释放,但当有新记录写入时,数据文件也不一定会增加,只有当新写入的数据量超过了删除的数 据量时,数据文件的大小才会增加。原来mysql会自行利用逻辑上被释放的空间! 申请之后不再主动释放,自行内部管理,除非进行optimize table! 我们的MySQl版本是 Server version: 5.1.34-community-log MySQL Community Server,运用optimize table 出现错误: Table does not support optimize, doing recreate + analyze instead 看到MySQL管网对optimize语法有详细的说明: You can makeOPTIMIZE TABLE work on other storage engines by starting mysqld with the –skip-new or –safe-mode option. In this case, OPTIMIZE TABLE is just mapped to ALTER TABLE. 上面是说要求我们在启动的时候指定–skip-new或者–safe-mode选项来支持optimize功能。 马上添加 添加选项启动,问题解决。 硬盘有所减少,但是还有大量空间未释放。怎么回事呢?注意到/var/lib/mysql/有很多“mysql-bin.000XXX的文件,才发现是文件mysql 日志惹的祸。因为程序已经实现备份,所以就把log删掉 mysql>reset master; (清除日志文件) 屏蔽 log-bin 在/etc/my.cnf 下修改 log-bin=mysql-bin 为注释状态,重启Mysql! 问题解决!释放了120G的空间… 参考信息 有时候发现mysql-bin.000001、mysql- bin.000002等文件占用了空间,那么这些文件是干吗的?这是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没 有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。 这样做主要有以下两个目的: 1:数据 恢复 如果你的数据库出问题了,而你之前有过备份,那么可以看日志文件,找出是哪个命令导致你的数据库出问题了,想办法挽回损失。 2:主从 服务器之间同步数据 主服务器上所有的操作都在记录日志中,从服务器可以根据该日志来进行,以确保两个同步。 处理方法分两种情况: 1: 只有一个mysql服务器,那么可以简单的注释掉这个选项就行了。 vi /etc/my.cnf把里面的log-bin这一行注释掉,重启mysql服务即可。 2:如果你的环境是主从服务器,那么就需要做以下操作了。 A: 在每个从属服务器上,使用SHOW SLAVE STATUS来检查它正在读取哪个日志。 B:使用SHOW MASTER LOGS获得主服务器上的一系列日志。 C:在所有的从属服务器中判定最早的日志,这个是目标日志,如果所有的从属服务器是更新的,就是清单上的最 后一个日志。 D:清理所有的日志,但是不包括目标日志,因为从服务器还要跟它同步。 清理日志方法为: PURGE MASTER LOGS TO ‘mysql-bin.010′; PURGE MASTER LOGS BEFORE ‘2008-12-19 21:00:00′; 如果你确定从服务器已经同步过了,跟主服务器一样了,那么可以直接RESET MASTER将这些文件删除。 Generated by Bo-blog 2.1.1 Release