Mysql:The table‘xxxx’is full

下午跑程序，在插入mysql时突然报错：

”The table‘xxxx’is full“

而之前一直没问题的。

上网查了一下，都说临时表的问题，需要设置”tmp_table_size“：

tmp_table_size 

如果内存内的临时表超过该值，MySQL自动将它转换为硬盘上的MyISAM表。如果你执行许多高级GROUP BY查询并且有大量内存，则可以增加tmp_table_size的值。

http://www.2cto.com/database/201106/92968.html

感觉与我们服务器情况不太相符：我们没用到临时表，而且tmp_table_size已经非常大了。

再查到：

mysql出现"the table is full"的问题,一般有两个原因:

一 .You are using the MEMORY (HEAP) storage engine; in this case you need to increase the value of the max_heap_table_size system variable. See Section 5.1.3, “Server System Variables”.

于是就修改Mysql的配置文件/etc/my.cnf，在[mysqld]下添加/修改两行：
tmp_table_size = 256M
max_heap_table_size = 256M

系统默认是16M，修改完后重启mysql

二.硬盘空间满了,清理硬盘即可.

http://linux.net527.cn/fuwuqiyingyong/Mysql_shujuku/2011/1003/44014.html

在服务器df了一下，果然硬盘空间不够了，已经使用了100%。

追查下来，发现是mysql的日志文件将硬盘撑爆了，有大量的mysql-bin.000XXX之类的日志文件。

如何处理？很简单：

（1）清除这些日志文件

（2）如果不需要的话，可以关闭mysql的bin-log功能。

具体操作：

这是数据库的操作日志，例如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将这些文件删除。

======================================

如何删除mysql-bin.0000X 日志文件呢?

mysql> reset master; (清除日志文件)
Query OK, 0 rows affected (8.51 sec)

mysql>

好了,我们再来查看下mysql文件夹占用多少空间?

[root@jiucool var]# du -h –max-depth=1 /usr/local/mysql/
37M /usr/local/mysql/var
70M /usr/local/mysql/mysql-test
15M /usr/local/mysql/lib
448K /usr/local/mysql/include
2.9M /usr/local/mysql/share
7.6M /usr/local/mysql/libexec
17M /usr/local/mysql/bin
11M /usr/local/mysql/docs
2.9M /usr/local/mysql/sql-bench
163M /usr/local/mysql/

好了,看一下,整个mysql 目录才占用163M大小!OK,没问题,既然mysql-bin.0000X日志文件占用这么大空间,存在的意义又不是特别大,那么我们就不让它生成吧.

[root@jiucool var]# find / -name my.cnf 

找到了my.cnf 即mysql配置文件,我们将log-bin=mysql-bin 这条注释掉即可.

# Replication Master Server (default)
# binary logging is required for replication
#log-bin=mysql-bin

重启下mysql吧.

OK,至此,操作完成. 以后再不会因为就几十M的数据库大小生成N个G的日志文件啦.

http://blog.csdn.net/alishun/article/details/5084318

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啊，删除后那个畅快的感觉难以形容。

重新启动我的服务器，现在健步如飞，爽就一个字。
一些建议