Mysql:The table‘xxxx’is full

死siua11

　　自从我博客转过来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啊，删除后那个畅快的感觉难以形容。
　　重新启动我的服务器，现在健步如飞，爽就一个字。
　　一些建议