記一次mysql故障處理

標籤：abort   local   dir   inux   存在   mpi   lib   shu   port   

突然間，個人網站崩潰了！相信這個報錯作為營運都應該清楚的，是資料庫宕機了。

資料庫我採用mysql 5.1.63，上機查看錯誤記錄檔：

171010 10:11:01 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var
171010 10:11:01 InnoDB: Initializing buffer pool, size = 512.0M
171010 10:11:01 InnoDB: Error: cannot allocate 536887296 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 22442704 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
171010 10:12:01InnoDB: Fatal error: cannot allocate the memory for the buffer pool
171010 10:12:01 [ERROR] Plugin ‘InnoDB‘ init function returned error.
171010 10:12:01 [ERROR] Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.
171010 10:12:01 [ERROR] Unknown/unsupported table type: INNODB
171010 10:12:01 [ERROR] Aborting

171010 10:12:01 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete

171010 10:12:01 mysqld_safe mysqld from pid file /usr/local/mysql/var/qyi-599a87c5e1fa7.pid ended
^C

我以為是innoDB引擎的壞掉了，於是重新編譯安裝了mysql,後來才發現，原來是設定檔中
innodb_buffer_pool_size 設定的值過大了，(我設定了1G) 呵呵 ，緩衝池過大了，雲端服務器上的記憶體不過也就才1G。

查了資料得知原因:

這個報錯的大意是,記憶體基本耗盡,沒有再可以分配的記憶體.

解決辦法:查看/etc/my.cnf,找innodb_buffer_pool_size,發現設值已經超過了系統總記憶體,然後重新設定為系統記憶體1半,即innodb_buffer_pool_size = 512M 重啟MySQL就OK了.

於是我修改my.cnf中參數：

innodb_buffer_pool_size         = 512M

 嘗試啟動mysql，結果不盡人意，依然報錯上述錯誤。

於是我方了。。。。。我嘗試各種方法，比如說初始化！！！！

一般來說初始化不會對線上資料造成什麼影響，但是~！生產環境可千萬不要這樣操作，萬一哪天不幸運，初始化完出故障了，那這個鍋你背定了。

按照我的想法繼續走。我本人是個菜鳥，寫這篇文章可能會被噴，是記憶體的問題為什麼要動資料？

我本人是個喜歡折騰的人，而且這個又是我的雲機器所以我當實驗機隨便折騰了。。好壞都無所謂。所以我這麼做，還可以鍛煉我對於mysql的理解呢，何樂而不為？

然後、、、初始化過後，我把datadir目錄下的資料全都刪了！！！！對沒錯，全刪了，或者是移到了其他不重要的目錄裡面去。

是什麼給了我這麼大勇氣刪資料庫？當然是binlog日誌哈哈哈，我可是對他做了備份呢。諾，你看。之前操作過的資料都會儲存在binlog日誌中，在其他沒有備份機制的情況下通過他可以備份出sql檔案，然後匯入MySQL。

mysqlbinlog --start-datetime="2017-09-30 16:41:00" --stop-datetime="2017-09-30 20:48:00" mysql-bin.000003 > wordpress.sql

好了，這次備份也有了我重新進到MySQL 的datadir目錄重新初始化，初始化完後目錄下會有兩個目錄分別是mysql、test

啟動mysql。這時候開啟另一個會話視窗查看日誌，我的心都要崩潰了。。。

跟上面報錯一模一樣，最後我沒辦法了，沒脾氣了，我直接reboot ！！哼哼這次看你還怎麼報錯。

linux記憶體管理是非常合理的，是不需要我們插手管理的，他會根據記憶體大小自動儲存到cache裡。當然這次的重啟就是為了釋放記憶體，有人說我小題大做，手工釋放一次記憶體不就行了？我能告訴你我當時沒有想到這一點嘛。。。。看來我考慮的還不夠全面啊哈哈，還是欠缺考慮。這次是我的實驗機，下次如果是線上的業務機器不讓重啟那可就沒轍了，還有萬一重啟起不來可就完蛋了。不過一般企業為了資料安全起見，都會部署至少兩個或兩個以上的資料庫，做個主從，以備故障之需。上次線上機器mysql的innodb出現故障，還好只是sdb，於是我果斷刪除目錄重新初始化，然後再從MDB把資料給同步過來恢複了正常。

在Linux系統下，我們一般不需要去釋放記憶體，因為系統已經將記憶體管理的很好。但是凡事也有例外，有的時候記憶體會被緩衝佔用掉，導致系統使用SWAP空間影響效能，此時就需要執行釋放記憶體（清理緩衝）的操作了。我可真是傻，百度上有釋放記憶體的資料，我竟然沒有想到。哎，這裡記錄下一下吧。

設定檔/proc/sys/vm/drop_caches。這個檔案中記錄了緩衝釋放的參數，預設值為0，也就是不釋放緩衝。他的值可以為0~3之間的任一數字，代表著不同的含義：

0 – 不釋放

1 – 釋放頁緩衝

2 – 釋放dentries和inodes

3 – 釋放所有緩衝

接下來，我們需要將需要的參數寫進/proc/sys/vm/drop_caches檔案中，比如我們需要釋放所有緩衝，就輸入下面的命令：

#echo 3 > /proc/sys/vm/drop_caches

此指令輸入後會立即生效，可以查詢現在的可用記憶體明顯的變多了。

要查詢當前緩衝釋放的參數，可以輸入下面的指令：

#cat /proc/sys/vm/drop_caches

 好了重啟ok了，之前做了所有服務開機自啟動，發現mysql已經啟動成功了，但是資料目錄裡面沒有東西，原因是我剛才把它刪了哈哈哈。。。。

所以現在備份的sql檔案有作用了！！！

直接匯入  mysql < wordpress.sql 

大功告成！！！！！我的個人網站又可以訪問了。

 

記一次mysql故障處理