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

我发现当MySQL耗尽太多内存时就会发生这种情况。 This question和this post都有助于提供测试方法和解决方案。

对我来说，将其添加到我的/etc/mysql/my.cnf文件可以解决问题。

innodb_buffer_pool_size = 12M

以下是我决定分配多少内存的方法。启动除MySQL之外的所有内容并检查可用内存量。将InnoDB缓冲区设置为该数量的10％。对我来说这是12M。

Answer 2

有一些东西可以帮助您的安装在没有任何崩溃的情况下运行。我在过去使用WordPress时遇到过类似的问题，而且你可能没有正确使用你的InnoDB。从上面的日志的外观，以及帖子的详细信息，你添加了一个重要的交换，可能没有做任何事情，或使问题更严重......

首先，你的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。 MySQL可能永远不会触及4GB交换内存（因此，如果有的话，您的交换可能被Apache / PHP使用）。这可能就是它崩溃的原因。将InnoDB增加至少两倍，实际上我建议尝试在该缓冲区中使用完整的数据库，但我知道由于RAM限制，它实际上不可能。尝试瞄准1/2你的RAM大小，看看它与之前相比如何运行，降低或增加它取决于你的结果。 MySQL Workbench有一个“服务器状态”工具，可以让你熟悉你的InnoDB缓冲区使用情况，理想情况下你希望它在不到100％（理想情况下为80-90％）的情况下运行，并且有足够的冗余空间以防万一。

快速说明：如果你将整个数据库放入RAM，你需要做更强大的工作。频繁的数据库备份（它是不稳定的，如果一切都在那里，而系统失去你所搞砸的能力）。

如果这些仍然没有产生任何重大影响，那么请考虑为WP站点提供更强大的缓存。在每个请求上加载每个页面都会非常繁琐，并且可以毫不费力地解决。查看MySQL上的Server Stats页面，查看您的站点每秒运行的查询数，与每秒InnoDB读/写数相比。

Answer 3

我有一个类似的问题，并且能够最终修复它。

<强>背景

我尝试了一系列教程，建议调整我的MySQL安装和Apache配置，但没有运气。

识别问题

事实证明，我的网站遭受了针对WordPress xmlrpc.php文件的暴力攻击。

为了检查这一点，您应该查看您的apache2访问日志并查找可疑的POST请求。在我的例子中，我发现大量来自/xmlrpc.php文件的POST请求来自相同的IP地址（每秒约2或3个请求）。

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/

Answer 4

我有一个类似的问题，根本原因是记忆。我的主人建议我做以下步骤并修复了问题

打开MySQL配置文件。

$ sudo nano /etc/mysql/my.cnf
更改以下行：

max_connections = 50

key_buffer = 25M

max_allowed_packet = 1M

thread_stack = 128K

table_cache = 25

MySQL一直在崩溃

4 个答案: