MySQL不断崩溃

Question

我有一台运行 Ubuntu 12.10 的云服务器，512Mb 的 RAM 仅用于运行 wordpress 网站（每天访问量约为 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 使用太多 RAM 时会发生这种情况。 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

我有一个类似的问题，根本原因是内存。我的主人建议我执行以下步骤并解决了问题

1. 打开 MySQL 配置文件。

   $ sudo nano /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 地址的 /xmlrpc.php 文件的大量 POST 请求（大约每秒 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/