網站總是掛掉，查看到原來是mysql總是莫名其妙的掛掉
1.查看mysql日志的位置
mysql> show VARIABLES like '%log%'; +-----------------------------------------+------------------------------------- ----------+ | Variable_name | Value | +-----------------------------------------+------------------------------------- | | log_error | /var/log/mysqld.log | | log_output | FILE | | +-----------------------------------------+------------------------------------- ----------+ 41 rows in set (0.05 sec)
可得知mysql日志文件位於/var/log/mysqld.log
2.使用vim /var/log/mysqld.log 查看錯誤日志最后面發現如下內容
150401 15:10:17 [ERROR] /usr/local/mysql/bin/mysqld: Disk is full writing './erqilu_87/pw_log_userdefend.MYD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
原來是磁盤空間滿了
3.查看磁盤空間
[root@AY121231034820cd91077 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 20G 20G 12M 100% / tmpfs 498M 0 498M 0% /dev/shm /dev/xvdb1 69G 21G 45G 32% /home
原來真的是爆滿啊。。。。
4.查看具體那些文件占用了磁盤空間
[root@AY1212334820cd91077 ~]# du -h --max-depth=1 / 4.1G /var 4.1G /root 97M /lib 156M /tmp 21G /home 11M /sbin 0 /opt 6.2M /bin 6.5G /usr 30G /
du 命令補習班 { du -h --max-depth=1 / 這句話的意思是列舉出（du）“/”目錄下深度為一個文件夾（--max-depth=1）的文件夾的大小並且以人能夠看懂的方式表現（-h）也就是M,G,KB什么的 }
可以看到home文件夾最大，不過這個文件夾在第2步的時候已經知道了不是和mysql的文件掛在在同一個磁盤的
其次就是/usr文件夾還有/var文件夾
5.解決/usr文件夾的容量問題
依然使用du命令查看/usr文件夾
發現原來是/usr/local/nginx/logs文件夾中的nginx的日志文件太大了而且還有以前用vim打開的時候因為沒有正確關閉而導致的swp文件，整個/usr/nginx/logs文件夾整整有6.4G
首先刪除所有的swp文件和swo文件，一下子就清爽了許多
然后想着要定期的刪除以下log文件，涉及到的知識有logrotate日志管理工具（參見我的另一篇日志）
打開/etc/logrotate.d/文件夾新建一個sample文件寫入以下內容
/usr/local/nginx/logs/erqilu.access.log{ olddir /usr/local/nginx/logs/oldErqiluAccessLogs //指定舊文件的存儲文件夾 weekly //指定每周執行一次 dateext //指定轉存后的文件以文件名+日期來命名 rotate 8 //指定保存八個轉存的文件 create 0644 root utmp //指定轉存后創建新的文件權限和原來一樣 sharedscripts prerotate //執行前的動作的開始標志 /usr/bin/chattr -a /usr/local/nginx/logs/erqilu.access.log //將/usr/local/nginx/logs/erqilu.access.log變成不可追加字符串 endscript //執行前的動作的結束標志 postrotate //執行后的動作的開始標志 /usr/bin/chattr +a /usr/local/nginx/logs/erqilu.access.log //將/usr/local/nginx/logs/erqilu.access.log 變成可以追加字符 /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/bull || true //重新啟動syslog進程 syslogd.pid中存儲的是打開syslogd進程的時候分配的進程號 /bin/kill -HUP `cat /usr/local/nginx/logs/nginx.pid ` //重新啟動nginx（nginx.pid文件中存儲的是打開nginx服務的時候的進程號） endscript //執行后動作的結束標志 }
然后使用命令：logrotate -f /etc/logrotate.d/sample 強制這個文件執行，
然后就會發現在 olddir /usr/local/nginx/logs/oldErqiluAccessLogs 多了一個erqilu.access.log-20150403而原來的那個文件也已經清空了，
在查看erqilu.access.log-20150403沒有發現有什么問題之后，就將erqilu.access.log-20150403刪除或者多執行幾次：logrotate -f /etc/logrotate.d/sample
刪除大文件之后，如果我們的配置正確的話，會每周都執行一次並且最大會保存八個歷史文件，如果超出了八個就將最古老的那個文件刪除
6.解決/var文件夾容量的問題
依然使用du命令發現占用空間最大的是/var/lib/mysql文件夾
打開一看不知道神馬時候被人插入的數據庫，使用phpmyadmin工具查看全是賣…………@#￥%……&*的
直接使用phpmyadmin將這個數據庫刪了，並且優化了一下數據庫。
在這個文件夾中還有一個ibdata1文件，有幾百M，經過查詢時innodb類型的數據庫產生的結構文件，並且如果數據庫改動的話，這個文件並不會縮小，只會慢慢變大
還有兩個幾十M的文件ib_logfile0、ib_logfile1，經過查詢，這些文件是myisam結構的數據庫產生的結構文件
解決的辦法如下
- 停止mysql的運行，
- 將服務器上的所有數據庫備份（推薦使用phpmyadmin，教程可以看我的另一篇日志）
- 將服務器上面的所有數據庫刪除
- 將ibdata1、ib_logfile0、ib_logfile1全部刪除，
- 恢復原來備份的整個服務器的數據庫
//蛋疼的是這樣做太費事兒了，而且只是能將ibdata1這個文件縮小，得不償失，放棄這個目標
經過這些步驟之后再次查看磁盤占用
[root@AY121231034820cd91077 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 20G 13G 6.6G 67% / tmpfs 498M 0 498M 0% /dev/shm /dev/xvdb1 69G 21G 45G 32% /home
世界終於清靜了