<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[沧海一粟]]></title> 
<link>http://www.dzhope.com/index.php</link> 
<description><![CDATA[Web系统架构与服务器运维,php开发]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[沧海一粟]]></copyright>
<item>
<link>http://www.dzhope.com/post//</link>
<title><![CDATA[mysql “log-bin”引起的linux空间不足 【转】]]></title> 
<author>jed &lt;jed521@163.com&gt;</author>
<category><![CDATA[服务器技术]]></category>
<pubDate>Wed, 23 Jun 2010 22:38:37 +0000</pubDate> 
<guid>http://www.dzhope.com/post//</guid> 
<description>
<![CDATA[ 
	这两天在做数据的汇总与统计，统计去年12月份到现在的数据，数据全部以小时暂存到了文件里面，每个文件都有几百兆，算起来每个文件有接近十万条记录，程序做了两天周一回来发现只做了十几个文件，这些速度太慢了。然后想到，把表升级到内存表来做汇总。汇总完以后分类存到硬盘。这样看起来速度快了，很多…<br/><br/><br/>但是今天早上起来本来想着肯定是要处理了几十个，结果来了一看，杯具了：数据库提示提示硬盘满了！<br/>LOG:<br/>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)<br/><br/>discuz论坛js无法更新，附件无法上传。<br/><br/>有220G的硬盘怎么就满了呢？是数据文件太多了？<br/>查看了下，发现home 占用了接近80G 空间。<br/><br/><br/>[root@localhost ~]# du -h –max-depth=1 /home<br/>78G&nbsp;&nbsp;&nbsp;&nbsp; /home<br/><br/>那么文件会是跑到哪里去了呢?<br/>&nbsp;&nbsp; 一个邪恶的念头突然蹦出来了：不是服务器被攻击了吧？黑客用我们做了文件服务器？那样可就惨了…<br/><br/>&nbsp;&nbsp; 一个一个查，最后定位到了/var/lib/mysql/下，哦！突然想起来了，是不是数据库太大了，文件太多了？数据库记录是比较多，但是也不至于有120G吧？百度一下，网上说了，mysql数据库记录输入删<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 掉以后，MySQL没有自动释放硬盘空间，而是自己管理已经向操作系统申请的空间，可以通过optimize table语法或alter table TableName engine=****来实现空间的释放。<br/><br/>当表的记录被删除时，数据文件并不会即时释放，但当有新记录写入时，数据文件也不一定会增加，只有当新写入的数据量超过了删除的数<br/>据量时，数据文件的大小才会增加。原来mysql会自行利用逻辑上被释放的空间! 申请之后不再主动释放,自行内部管理,除非进行optimize table！<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp; 我们的MySQl版本是 Server version: 5.1.34-community-log MySQL Community Server，运用optimize table 出现错误：<br/><br/>Table does not support optimize, doing recreate + analyze instead<br/><br/>看到MySQL管网对optimize语法有详细的说明：<br/><br/>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.<br/><br/>上面是说要求我们在启动的时候指定–skip-new或者–safe-mode选项来支持optimize功能。<br/>马上添加 添加选项启动，问题解决。<br/>硬盘有所减少，但是还有大量空间未释放。怎么回事呢？注意到/var/lib/mysql/有很多“mysql-bin.000XXX的文件，才发现是文件mysql 日志惹的祸。因为程序已经实现备份，所以就把log删掉<br/><br/><br/>mysql>reset master; (清除日志文件)<br/><br/>屏蔽 log-bin<br/><br/>在/etc/my.cnf 下修改<br/><br/><br/>log-bin=mysql-bin<br/><br/>为注释状态，重启Mysql！<br/>问题解决！释放了120G的空间…<br/><br/>参考信息<br/><br/><br/>有时候发现mysql-bin.000001、mysql- bin.000002等文件占用了空间，那么这些文件是干吗的？这是数据库的操作日志，例如UPDATE一个表，或者DELETE一些数据，即使该语句没 有匹配的数据，这个命令也会存储到日志文件中，还包括每个语句执行的时间，也会记录进去的。<br/><br/>这样做主要有以下两个目的：<br/>1：数据 恢复<br/>如果你的数据库出问题了，而你之前有过备份，那么可以看日志文件，找出是哪个命令导致你的数据库出问题了，想办法挽回损失。<br/>2：主从 服务器之间同步数据<br/>主服务器上所有的操作都在记录日志中，从服务器可以根据该日志来进行，以确保两个同步。<br/><br/>处理方法分两种情况：<br/>1： 只有一个mysql服务器，那么可以简单的注释掉这个选项就行了。<br/>vi /etc/my.cnf把里面的log-bin这一行注释掉，重启mysql服务即可。<br/>2：如果你的环境是主从服务器，那么就需要做以下操作了。<br/>A： 在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。<br/>B：使用SHOW MASTER LOGS获得主服务器上的一系列日志。<br/>C：在所有的从属服务器中判定最早的日志，这个是目标日志，如果所有的从属服务器是更新的，就是清单上的最 后一个日志。<br/>D：清理所有的日志，但是不包括目标日志，因为从服务器还要跟它同步。<br/>清理日志方法为：<br/>PURGE MASTER LOGS TO ‘mysql-bin.010′;<br/>PURGE MASTER LOGS BEFORE ‘2008-12-19 21:00:00′;<br/><br/>如果你确定从服务器已经同步过了，跟主服务器一样了，那么可以直接RESET MASTER将这些文件删除。 <br/><br/><br/>Tags - <a href="http://www.dzhope.com/tags/linux/" rel="tag">linux</a> , <a href="http://www.dzhope.com/tags/%25E7%25A9%25BA%25E9%2597%25B4%25E4%25B8%258D%25E8%25B6%25B3/" rel="tag">空间不足</a> , <a href="http://www.dzhope.com/tags/mysql/" rel="tag">mysql</a> , <a href="http://www.dzhope.com/tags/log-bin/" rel="tag">log-bin</a>
]]>
</description>
</item><item>
<link>http://www.dzhope.com/post//#blogcomment</link>
<title><![CDATA[[评论] mysql “log-bin”引起的linux空间不足 【转】]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://www.dzhope.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>