MySQL bin_log文件真让我胆颤心惊
自从我博客转过来Linode之后，一直其实我很少去理会服务器的运行情况，反正博客能上，我就准时交款给Linode。可是近来突然发现好几次博客无法登录，即使重新启动了服务器也解决不了。当我重新启动MySQL服务器的时候，就会有下面的失败语句：
MySQL manager or server PID file could not be found!! failed
意思就是MySQL管理器或者无法找到服务器PID文件，所以我开始向Linode的客服询问情况和解决方法，我在这里先说明一下，因为Linode销售的是自己管理的VPS服务器，所以理论上来说你的VPS上面所有东西应该都是自己管理的，Linode的客服没有任何责任需要去帮你，但是我不得不赞扬一下Linode的客服（特别是Peter，虽然他未必看得到这句话），他们并没有用“去Google”或者“上Linode的知识库找”等等来让我自己去受苦。
因为我当时发现问题的时候，已经是凌晨1点多了，给客服发了电子邮件，15分钟后，Peter开始联络我，当一轮的指引后，我还是无法解决问题──也因为我对Linux不太熟悉，当时已经是凌晨3点了，而第二天我需要开车去美国。所以我询问Peter，看看他能否帮我管理，他说“一般我们不应该这样子做，但是为了让你可以睡个好觉，你让我take the wheel（让我来帮你开车，也就是说他帮我找问题所在和尝试解决）吧。
第二天，我睡醒的时候，看到一封来自Peter的信，他说一个好消息，一个坏消息。好消息就是找到问题的所在──我的空间不够了，坏消息就是，我需要清理一些文件或者购买多一些空间。
这个不是问题，我马上清理了大概1GB的垃圾文件，这对于博客来说，应该足够了。做了之后，我的MySQL服务器马上可以运行，而博客也正常。
可惜，这个维持不到一个星期，两天前，我的博客再次发生同样问题，因为这次我有了经验，就先购买了1GB硬盘空间（才$2一个月，很便宜），先让博客重新运作。但是这个不是办法，我必须找出究竟是什么占了这么大的空间。
我想了想，我的Linode放了三个博客，分别是rockia.com、rockia.net还有ipanda.ca，三个都是Wordpress，基本上可以占用到空间绝对不到2GB，而我的Linode安装了Debian5 Lenny的Linux版本，应该也不会超过3GB（加上Nginx服务器和附加软件），那么也就是说我的Linode 16GB空间，应该还有至少11GB的空间。按照这个算法，肯定是有什么垃圾文件在我的服务器上面，所以我就从根目录开始找这些文件。
因为用root来ssh连接到我的服务器，没有任何GUI界面，所以只可以用命令行来查看我的文件，这里我首先要介绍一个Linux下面很好用的命令 “du”，而更加好用的就是加上参数”-h”，这个参数可以用人类可读的方法来标出查询的文件夹的大小，例如 kb, mb,gb等。
我查看到在 /usr/local/mysql/var下面，一共占用了我13GB的空间，天啊！13GB！而看到一大堆文件都是这样的格式：
mysql-bin.000011 mysql-bin.000026 mysql-bin.000041 mysql-bin.000056 mysql-bin.000071 mysql-bin.000086 mysql-bin.000101 mysql-bin.000116
li158-206.err mysql-bin.000012 mysql-bin.000027 mysql-bin.000042 mysql-bin.000057 mysql-bin.000072 mysql-bin.000087 mysql-bin.000102 mysql-bin.000117
li158-206.err-old mysql-bin.000013 mysql-bin.000028 mysql-bin.000043 mysql-bin.000058 mysql-bin.000073 mysql-bin.000088 mysql-bin.000103 mysql-bin.000118
li158-206.pid mysql-bin.000014 mysql-bin.000029 mysql-bin.000044 mysql-bin.000059 mysql-bin.000074 mysql-bin.000089 mysql-bin.000104 mysql-bin.000119
mysql mysql-bin.000015 mysql-bin.000030 mysql-bin.000045 mysql-bin.000060 mysql-bin.000075 mysql-bin.000090 mysql-bin.000105 mysql-bin.000120
mysql-bin.000001 mysql-bin.000016 mysql-bin.000031 mysql-bin.000046 mysql-bin.000061 mysql-bin.000076 mysql-bin.000091 mysql-bin.000106 mysql-bin.000121
mysql-bin.000002 mysql-bin.000017 mysql-bin.000032 mysql-bin.000047 mysql-bin.000062 mysql-bin.000077 mysql-bin.000092 mysql-bin.000107 mysql-bin.000122
mysql-bin.000003 mysql-bin.000018 mysql-bin.000033 mysql-bin.000048 mysql-bin.000063 mysql-bin.000078 mysql-bin.000093 mysql-bin.000108 mysql-bin.000123
mysql-bin.000004 mysql-bin.000019 mysql-bin.000034 mysql-bin.000049 mysql-bin.000064 mysql-bin.000079 mysql-bin.000094 mysql-bin.000109 mysql-bin.000124
mysql-bin.000005 mysql-bin.000020 mysql-bin.000035 mysql-bin.000050 mysql-bin.000065 mysql-bin.000080 mysql-bin.000095 mysql-bin.000110 mysql-bin.000125
mysql-bin.000006 mysql-bin.000021 mysql-bin.000036 mysql-bin.000051 mysql-bin.000066 mysql-bin.000081 mysql-bin.000096 mysql-bin.000111 mysql-bin.000126
mysql-bin.000007 mysql-bin.000022 mysql-bin.000037 mysql-bin.000052 mysql-bin.000067 mysql-bin.000082 mysql-bin.000097 mysql-bin.000112 mysql-bin.index
mysql-bin.000008 mysql-bin.000023 mysql-bin.000038 mysql-bin.000053 mysql-bin.000068 mysql-bin.000083 mysql-bin.000098 mysql-bin.000113
mysql-bin.000009 mysql-bin.000024 mysql-bin.000039 mysql-bin.000054 mysql-bin.000069 mysql-bin.000084 mysql-bin.000099 mysql-bin.000114
mysql-bin.000010 mysql-bin.000025 mysql-bin.000040 mysql-bin.000055 mysql-bin.000070 mysql-bin.000085 mysql-bin.000100 mysql-bin.000115
其中有好几个都是占用了1.1GB。就是这些垃圾，让我好好的博客无法访问，也是这些文件，让我连1KB的文件也无法写进去MySQL数据库，当然也无法启动。
究竟这些是什么文件？
这些文件是叫做MySQL Binary Log，主要有下面两个作用：
- 数据恢复。
- 在主从服务器上提高复制的可靠性。这个其实是主要的作用，但是我根本没有主从服务器，我只有一个，所以用不着，对不？
如何解决？
既然知道问题所在，我就知道怎么去做，首先当然是要杜绝问题重复发生，ssh 登录然后运行 /usr/local/mysql/bin/mysql -u root -p 登录执行：
reset master;
在/etc/ 下面找到my.cnf把
#log-bin=mysql-bin
#binlog_format=mixed
这两行注释掉，然后将这些文件全部删除，13GB啊，删除后那个畅快的感觉难以形容。
重新启动我的服务器，现在健步如飞，爽就一个字。
一些建议
洛奇亚对于Linux服务器也是不熟悉，但是经过了这些在灾难，起码学会了一招去管理服务器。虽然说VPS的好处好多，但是如果你的博客如果不是到了虚拟服务器无法支持的时候（一般是日5000PV，当然我远远没有达到这个数字，我用VPS单单因为我想学用服务器而已），千万不要冒险取用，否则很很多事情未必可以第一时间解决。
另外，再次赞扬一下Linode的客服，15分钟回复，而且尽力帮我解决问题，很少看到这个年代还有这么好的客服。如果大家在找VPS，相差不是太多钱的时候，不如考虑一下Linode。
最新评论
貌似3.16只是北京的用户
我木有任何压力，我一直是实名。
很少翻墙，拭目以待实名制后的结果，新浪微博会不会哭啊！
翻墙，累啊！
这是必然的趋势，当微博第一时间频频暴出各种不和谐信息的时候就注定了微博的结果。我只想说即将消失一个爆料平台，还是那四个字“MLGB”
- Older »
25个评论
真的要知道了呀！不然以后换成Linux怎么办了呀！
其实跟Linux没有什么关系，是MySQL服务器的设置而已，如果你有足够大的硬盘，bin_log不影响速度的，而且对于数据库维护有一定的帮助，但是因为我用的是VPS，而不是自己的服务器，所以硬盘空间方面有限制。
这个是mysql的原因呀！估计还是设置问题吧!
对，是设置问题，但是我采用的是默认安装，所以相信很多朋友都会遇到这个问题。不过现在已经重新修改了，相信没有问题了。
哦，这些东西还真不懂，呵呵～
唉，没有任何Linux的背景去用VPS，还真的困难，不过说真的，可以学到东西。
一看就知道你狠偷懒，
mysql也默认安装
能够偷懒就偷懒啊，不喜欢折腾太多。
出了问题都很麻烦的
还好现在解决了，我本来以为这次我的博客死定了，所以以后我需要好好注意数据库的备份了。
哥 这是软文吗？哈哈 LINUX服务器的确很难搞 看着命令行人就想吐
你看是软文吗？我连Linode服务器和我其他网站都没有加上链接标签，只是写名字出来，你看像么？我这博客不写软文，我也不会写，我只是写出来提醒一下而已，别这么敏感。
Linux服务器难搞，但是这么多人选用就是因为它的稳定性和低价，我可不希望架设了Windows服务器后经常要重启。命令行一开始比较难，但是熟悉了，一条命令比你GUI方便很多。
因为MySQL已经没有空间创建这个PID文件了，至于怎么生成这个文件，我也不清楚，反正现在重点不是在PID文件上，而是磁盘空间不够。
那个是你自己开启的吧……？
其实不算我开启的，而是我不知道的情况下没有关闭。
这个月刚刚退掉了linode，linode不错，可惜我那个代购不给我续费了！
代购的作用不就是帮你买吗？本来这就是工作，竟然你愿意付钱他也不代购？可惜我没有支付宝，不然我可以帮你，呵呵。
学习一下，我也是默认的啊
你如果有大硬盘空间可以无视的，否则，可能你需要看看你的MySQL安装设置，可能有惊喜哦，呵呵。
垃圾文件都有1G？
神奇吧？
还不敢用vps，这个先学习一下。
PS：你博客右边的朋友文章那个栏目怎么不见了
前阵子在rashost买的vps。T2的线路，很快，客服还不错，然后参与写软文送内存活动，一直没送齐全！（直到最后还没全部送完）因为rebuild是要提交ticket的，我当初研究radius+PPTP，提交了不少次，后来他干脆都不rebuild了！真气人，哪有这么烂的，真是一个天一个地。
最近我自己在我的服务器编译了mysql，也出现了一些问题，来学习了
都是我不注意的关系啊！
被引用2次
[...] 记得，我一个月前，博客遇到一个重大的问题，是关于我的VPS服务器的MySQL问题。如果我以前是在JustHost或者BlueHost那些虚拟空间，我第一件事情可能就是要去考虑换空间，因为我都会将问题归咎在第三方身上。但是我知道，选择了Linode，就意味着我选择了需要自己靠自己去解决问题，我总不能够就坐在那里等待奇迹或者抱怨自己这么这么笨选择了VPS需要自己来管理这些自己不熟悉的服务器问题。 [...]
[...] 1：清除二进制的日志。 参考这篇文章：http://www.rockia.net/2010/09/blog-stopped-for-one-whole-day-due-to-mysql-bin-log [...]