Mysql/InnoDB在Linode服务器上停止工作 [英] Mysql/InnoDB stop working on Linode Server

问题描述

我的MySQL服务器没有启动.当我检查error.log文件时，我发现了这一点.你能建议我该怎么做吗?

My MySQL server didn't start. When I check error.log file I found this. Can you please suggest me what to do?

151113  6:59:53 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
151113  6:59:53 [Note] Plugin 'FEDERATED' is disabled.
151113  6:59:53 InnoDB: The InnoDB memory heap is disabled
151113  6:59:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151113  6:59:53 InnoDB: Compressed tables use zlib 1.2.3.4
151113  6:59:53 InnoDB: Initializing buffer pool, size = 128.0M
151113  6:59:53 InnoDB: Completed initialization of buffer pool
InnoDB: Error: checksum mismatch in data file ./ibdata1
151113  6:59:53 InnoDB: Could not open or create data files.
151113  6:59:53 InnoDB: If you tried to add new data files, and it failed here,
151113  6:59:53 InnoDB: you should now edit innodb_data_file_path in my.cnf back
151113  6:59:53 InnoDB: to what it was, and remove the new ibdata files InnoDB created
151113  6:59:53 InnoDB: in this failed attempt. InnoDB only wrote those files full of
151113  6:59:53 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
151113  6:59:53 InnoDB: remove old data files which contain your precious data!
151113  6:59:53 [ERROR] Plugin 'InnoDB' init function returned error.
151113  6:59:53 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151113  6:59:53 [ERROR] Unknown/unsupported storage engine: InnoDB
151113  6:59:53 [ERROR] Aborting

151113  6:59:53 [Note] /usr/sbin/mysqld: Shutdown complete

推荐答案

我刚刚遇到了这个问题，最初以" dmesg 日志中的-mysql-mysql-respawning-too-fast-stopped> mysql重新生成速度太快"错误.

I've just had this, initially presenting itself as a "mysql respawning too fast" error in the dmesg logs.

从在其他地方阅读，我将其追溯到您找到的内容，而且我认为结果表明这表明InnoDB的元数据文件存在某种损坏.InnoDB做诸如确保事务/回滚完整性和主外键完整性的事情.这就是校验和不匹配"错误警告您的原因.

From reading elsewhere I traced it down to what you found, and I think worked out that this points to some kind of corruption in InnoDB's metadata files. InnoDB does things like ensuring transaction/rollback integrity and primary-foreign key integrity. That's what the "checksum mismatch" error is warning you of.

您没有说如何启动mysqld，但也许您在/etc/init.d/mysqld start 或 service mysqld start 上使用了一些变体代码>.而是直接将守护程序作为命令运行:

You don't say how you're starting mysqld, but maybe you're using some variant on either /etc/init.d/mysqld start or service mysqld start. Run the daemon explicitly as a command instead:

sudo /usr/sbin/mysqld --innodb_force_recovery 0

，并且，只要您知道为什么要这样做，就逐渐将-innodb_force_recovery 的零值递增，直到该过程开始.

and, as long as you know why you're doing it, gradually increment the zero value of --innodb_force_recovery until the process starts.

警告: innodb_force_recovery 参数确定mysqld将多么认真地尝试强制修复" InnoDB存储中的校验和错误.如果您在此处强行修复，那么您可能会使问题变得更糟，或者需要稍后进行索引重建，因为InnoDB会做越来越多的艰巨尝试来进行自我修复.

Warning: The innodb_force_recovery parameter determines just how seriously mysqld will try to "force-fix" the checksum error in the InnoDB storage. So you can make the problem worse, or need later index rebuilding, if you force-fix with a high number here, because InnoDB will do more and more drastic things to try to fix itself.

每次您都无法重启具有特定编号的 mysqld 时，例如 2 ，则应先搜索所收到的错误消息，然后再将其递增到 3 ，以确保执行正确的操作.我不是您可能会遇到的每个错误的专家，所以我无法为每种异常情况提供反馈:我要说的是，请小心使用-innodb_force_recovery ！

Every time you fail to restart mysqld with a particular number e.g. 2, you should search for the error messages you get before you increment it to 3 so you can be sure you're doing the right thing. I'm not an expert on every error you might get, so I can't provide feedback for every exceptional condition: all I'm saying is, use --innodb_force_recovery with care!

这篇关于Mysql/InnoDB在Linode服务器上停止工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！