下午跑程序，在插入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啊，刪除后那個暢快的感覺難以形容。
重新啟動我的服務器，現在健步如飛，爽就一個字。
一些建議