【问题标题】:MySQL crash on startupMySQL在启动时崩溃
【发布时间】:2016-03-17 20:42:56
【问题描述】:

我正在使用 wamp 在我的笔记本电脑上进行开发,而 mysql 从几周内运行良好。今天在启动mysql崩溃60秒后,我在日志中发现以下错误:

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。

这是我的.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 64 位上运行 mysql 32 位。

这是我可以通过改变一些变量来解决的问题吗?

非常感谢您的帮助

【问题讨论】:

  • 似乎您没有足够的空间 -2016-03-17T20:34:37.662021Z 0 [错误] InnoDB:在 60 秒内重试 60 次后无法分配 4294956804 字节的内存。操作系统错误:空间不足 (12)。
  • 磁盘空间如何?
  • 是的,我注意到错误...磁盘空间还可以。但是mysql尝试分配4Gb是不正常的,以前从来没有这样做过
  • 那么可能是 InnoDB 表空间中的损坏,就像错误消息中建议的那样..尝试相关链接进行恢复 -..
  • 但是 InnoDB 表空间的损坏如何导致 mysql 尝试分配 4Gb 的内存?

标签: mysql crash


【解决方案1】:

这可能是 InnoDB 数据损坏。我加了

innodb_force_recovery = 2

到 my.ini,重新启动数据库,我能够转储所有数据并恢复它。

注意使用这个,阅读之前的文档:http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

【讨论】:

    【解决方案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。

    这对我有用,祝你好运!

    【讨论】:

    • 在我的情况下,这只是我的 my.ini 在“innidb_data_home_dir”中的错误路径
    猜你喜欢
    • 1970-01-01
    • 2015-01-07
    • 2012-08-15
    • 2013-09-22
    • 2016-12-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多