mysql “log-bin”引起的linux空间不足 【转】 
这两天在做数据的汇总与统计，统计去年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将这些文件删除。
但是今天早上起来本来想着肯定是要处理了几十个，结果来了一看，杯具了：数据库提示提示硬盘满了！
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将这些文件删除。
Linux VPS下简单解决CC攻击
关于php处理多选框checkbox的方法
