MySQL不斷崩潰

Question

我有一臺運行ubuntu 12.10的雲服務器，512Mb的RAM只是運行一個wordpress網站（每aprox 1000訪問/天）。

的MySQL是跳投崩潰的話，我能4Gb的交換，看看能不能工作...但仍崩潰......我需要重新啓動該服務，每次...

檢查從MySQL我的錯誤日誌注意到InnoDB似乎處於一個循環試圖恢復的東西，但我認爲它不能...任何人都可以幫助我嗎？

131009 17:56:57 InnoDB: 5.5.32 started; log sequence number 242183133 
131009 17:56:57 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
131009 17:56:57 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
131009 17:56:57 [Note] Server socket created on IP: '127.0.0.1'. 
131009 17:56:57 [Note] Event Scheduler: Loaded 0 events 
131009 17:56:57 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 
131009 17:57:25 [Note] Plugin 'FEDERATED' is disabled. 
131009 17:57:25 InnoDB: The InnoDB memory heap is disabled 
131009 17:57:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
131009 17:57:25 InnoDB: Compressed tables use zlib 1.2.7 
131009 17:57:25 InnoDB: Using Linux native AIO 
131009 17:57:25 InnoDB: Initializing buffer pool, size = 128.0M 
131009 17:57:25 InnoDB: Completed initialization of buffer pool 
131009 17:57:25 InnoDB: highest supported file format is Barracuda. 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
131009 17:57:25 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
131009 17:57:26 InnoDB: Waiting for the background threads to start 
131009 17:57:27 InnoDB: 5.5.32 started; log sequence number 242183133 
131009 17:57:27 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
131009 17:57:27 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
131009 17:57:27 [Note] Server socket created on IP: '127.0.0.1'. 
131009 17:57:27 [Note] Event Scheduler: Loaded 0 events 
131009 17:57:27 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 
131009 17:58:05 [Note] Plugin 'FEDERATED' is disabled. 
131009 17:58:05 InnoDB: The InnoDB memory heap is disabled 
131009 17:58:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
131009 17:58:05 InnoDB: Compressed tables use zlib 1.2.7 
131009 17:58:05 InnoDB: Using Linux native AIO 
131009 17:58:05 InnoDB: Initializing buffer pool, size = 128.0M 
131009 17:58:05 InnoDB: Completed initialization of buffer pool 
131009 17:58:06 InnoDB: highest supported file format is Barracuda. 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
131009 17:58:06 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
131009 17:58:06 InnoDB: Waiting for the background threads to start 
131009 17:58:07 InnoDB: 5.5.32 started; log sequence number 242183143 
131009 17:58:07 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
131009 17:58:07 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
131009 17:58:07 [Note] Server socket created on IP: '127.0.0.1'. 
131009 17:58:07 [Note] Event Scheduler: Loaded 0 events 
131009 17:58:07 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 
131009 17:58:33 [Note] Plugin 'FEDERATED' is disabled. 
131009 17:58:33 InnoDB: The InnoDB memory heap is disabled 
131009 17:58:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
131009 17:58:33 InnoDB: Compressed tables use zlib 1.2.7 
131009 17:58:33 InnoDB: Using Linux native AIO 
131009 17:58:33 InnoDB: Initializing buffer pool, size = 128.0M 
131009 17:58:34 InnoDB: Completed initialization of buffer pool 
131009 17:58:34 InnoDB: highest supported file format is Barracuda. 
InnoDB: Log scan progressed past the checkpoint lsn 242183143 
131009 17:58:34 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
InnoDB: Doing recovery: scanned up to log sequence number 242183153 
131009 17:58:34 InnoDB: Waiting for the background threads to start 
131009 17:58:35 InnoDB: 5.5.32 started; log sequence number 242183153 
131009 17:58:35 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
131009 17:58:35 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
131009 17:58:35 [Note] Server socket created on IP: '127.0.0.1'. 
131009 17:58:35 [Note] Event Scheduler: Loaded 0 events 
131009 17:58:35 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 
131009 17:58:44 [Note] Plugin 'FEDERATED' is disabled. 
131009 17:58:44 InnoDB: The InnoDB memory heap is disabled 
131009 17:58:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
131009 17:58:44 InnoDB: Compressed tables use zlib 1.2.7 
131009 17:58:44 InnoDB: Using Linux native AIO 
131009 17:58:45 InnoDB: Initializing buffer pool, size = 128.0M 
131009 17:58:45 InnoDB: Completed initialization of buffer pool 
131009 17:58:45 InnoDB: highest supported file format is Barracuda. 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
131009 17:58:45 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
131009 17:58:45 InnoDB: Waiting for the background threads to start 
131009 17:58:47 [Note] Plugin 'FEDERATED' is disabled. 
131009 17:58:47 InnoDB: The InnoDB memory heap is disabled 
131009 17:58:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
131009 17:58:47 InnoDB: Compressed tables use zlib 1.2.7 
131009 17:58:47 InnoDB: Using Linux native AIO 
131009 17:58:47 InnoDB: Initializing buffer pool, size = 128.0M 
131009 17:58:47 InnoDB: Completed initialization of buffer pool 
131009 17:58:47 InnoDB: highest supported file format is Barracuda. 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
131009 17:58:47 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
131009 17:58:47 InnoDB: Waiting for the background threads to start 
131009 17:58:48 InnoDB: 5.5.32 started; log sequence number 242183153 
131009 17:58:48 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
131009 17:58:48 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
131009 17:58:48 [Note] Server socket created on IP: '127.0.0.1'. 
131009 17:58:48 [Note] Event Scheduler: Loaded 0 events 
131009 17:58:48 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 

Answer 1

有幾件事情可以幫助您的安裝在沒有任何崩潰的情況下運行。我以前在使用WordPress時遇到過類似的問題，很可能是您沒有正確使用您的InnoDB。從上面日誌的外觀以及帖子中的詳細信息中，您已經添加了一個重要的Swap，它可能或者什麼都沒做，或者使問題變得更糟......

首先，你的4GB交換內存對於這樣一個小型服務器來說太高了。大部分進程可能通過交換內存使用。將交換內存減少到512MB或1GB，並從那裏進行故障排除。第二件事是檢查交換配置。如果它太高，那麼你的系統將積極使用交換內存 - 這會浪費週期，並且會減慢數據恢復速度，如果太慢，那麼根本就沒有它。默認值是60，我建議從10開始，從那裏開始工作，直到找到服務器的「最佳位置」。查看這篇Ubuntu文章，瞭解如何在您的系統上進行更改： https://help.ubuntu.com/community/SwapFaq#What_is_swappiness_and_how_do_I_change_it.3F

您的InnoDB緩衝區很小，爲128.0MB。 4GB交換內存可能永遠不會被MySQL觸及（因此，如果有的話，你的交換可能被Apache/PHP使用）。這可能是它崩潰的原因。將InnoDB增加至少兩倍，實際上我會建議嘗試將緩衝區中的完整數據庫，但是我知道由於內存限制，這是不可能的。試着瞄準你的內存容量的1/2，看看它是如何運行的，然後根據你的結果降低或增加它。 MySQL Workbench具有一個「服務器狀態」工具，可以將您的InnoDB緩衝區使用率視爲您的理想情況，您希望它在100％（理想情況下爲80-90％）的情況下運行，並具有足夠的冗餘空間以防止出現任何尖峯。

快速提示：如果您將整個數據庫放入RAM中，則需要進行更頻繁的db備份（它是不穩定的，並且如果一切都在那裏，並且系統失去了您擰緊的電源），則需要更加健壯的&。

如果這些仍然沒有產生任何重大影響，那麼請查看您的WP網站的更強大的緩存。在每個請求中加載每個頁面都會非常麻煩，並且可以在不付出太多努力的情況下解決。查看MySQL上的「服務器統計」頁面，並查看您的網站每秒運行的查詢數量，與InnoDB每秒讀寫數量相比。

Answer 2

我發現這發生在MySQL使用了太多的RAM時。 This question和this post都有助於測試和解決方案。

對我而言，將此添加到我的/etc/mysql/my.cnf文件中修復了此問題。

innodb_buffer_pool_size = 12M 

下面是我如何決定分配多少內存。啓動除MySQL以外的所有內容，並檢查有多少內存空閒。將您的InnoDB緩衝區設置爲該數量的10％。對我來說，這是12M。

Answer 3

我有一個類似的問題，根本原因是內存。我的主機建議我執行以下步驟並修復問題

1. 打開MySQL配置文件。

   $須藤納米/etc/mysql/my.cnf

2. 更改下列行：

   MAX_CONNECTIONS = 50

   的key_buffer = 25M

   max_allowed_pa​​cket的= 1M

   thread_stack = 128K

   table_cache = 25

Answer 4

我有一個類似的問題，並能夠最終解決它。

背景

我試過，建議調整我的MySQL安裝和Apache的配置，沒有運氣了一堆教程。

確定問題

事實證明，我的網站正在遭受暴力攻擊，有針對性WordPress的xmlrpc.php文件。

爲了檢查這個，你應該查看你的apache2訪問日誌並尋找可疑的POST請求。就我而言，我發現來自相同IP地址（每秒約2或3個請求）的大量POST請求到/xmlrpc.php文件。

cd /var/log/apache2/ 
cat access.log 

解決方案

爲了解決這個問題，我禁止通過iptables的違規IP地址：

潘基IP的惡意IP地址（與任何IP地址，你要禁止替代例子）：

iptables -A INPUT -s 46.166.139.20 -j DROP 

要查看阻止IP地址：

iptables -L INPUT -v -n 

參考： http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/