mysql “log-bin”引起的linux空间不足 【转】 不指定

jed , 2010-6-24 06:38 , 服务器技术 , 评论(0) , 阅读(3579) , Via 本站原创 | |
这两天在做数据的汇总与统计,统计去年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将这些文件删除。

发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]