Question

我在我的笔记本电脑上使用wamp进行开发，mysql在几周内运行良好。今天启动60秒后，mysql崩溃，并在日志中找到以下错误：

2016-03-17T20:34:37.662021Z 0 [ERROR] InnoDB: Cannot allocate 4294956804 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b74  InnoDB: Assertion failure in thread 11124 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:34:37 UTC - mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=67108864
read_buffer_size=2097152
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 685380 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x103288c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
2016-03-17T20:34:37.682021Z 0 [ERROR] InnoDB: Cannot allocate 4294954524 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b58  InnoDB: Assertion failure in thread 11096 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

对我而言，似乎存在内存问题：

[ERROR] InnoDB：60后无法分配4294956804字节的内存重试超过60秒。操作系统错误：空间不足（12）。

崩溃是由于这个错误造成的吗？奇怪的是mysql尝试分配4Gb的ram，通常它使用或多或少500Mb。

这是my.ini：

innodb_buffer_pool_size = 16M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

我在win7 64bit上运行mysql 32位。

这是我能解决的改变某些变量吗？

非常感谢你的帮助

Answer 1

这可能是InnoDB数据的破坏。我添加了

innodb_force_recovery = 2

到my.ini，重新启动数据库，我就可以转储所有数据并恢复它。

请注意使用此功能，请阅读以下文档：http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

Answer 2

我在CentOS VPS上有类似的问题，而Stefano Giacone的回答基本上就是我所做的，所以它经过数小时的研究和很多压力后才起作用......

步骤是：

1）找到my.cnf文件（我的位于/etc/my.cnf）并添加以下行：

innodb_force_recovery = X

用1到6之间的整数替换X，从1开始，然后在MySQL无法启动时递增。设置为4,5或6可以删除您的数据，因此请小心并在之前阅读http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html。

2）重启MySQL服务。此时只会运行SELECT，这是正常的。

3）将所有数据库/模式逐个转储到mysqldump，不要压缩转储，因为无论如何你必须在6）中解压缩它们。

4）仅移动（或删除！）/ var / lib / mysql中的bd目录，保留根目录中的各个文件。

5）停止MySQL，然后取消注释1）中添加的行。启动MySQL。

6）恢复3）中倾倒的所有bd。

这对我有用，祝你好运！

MySQL在启动时崩溃

2 个答案: