MySQL不启动后崩溃问题，怎么解决

Posted 2023-05-10

mysql 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。 参考技术A 解决方法一：　　
1、打开my.ini文件，找到default-storage-engine=InnoDB这一行，把它改成default-storage-engine=MyISAM； 　　
2、删除在MySQL安装目录下的Data目录中的ib_logfile0和ib_logfile1；
3、找到在配置MySQL服务器时指定的InfoDB目录删除掉ibdata1 　　
根据my.ini文件中：#*** INNODB Specific options *** innodb_data_home_dir="D:/"；
4、重新启动MySQL的Service。 　　
解决方法二：
把windows目录下，my.ini文件删除，重装mysql,服务启动成功。本回答被提问者采纳 参考技术B 对于新手来说，卸载重装是最快的

XAMPP：崩溃后 MySQL 不启动

【中文标题】XAMPP：崩溃后 MySQL 不启动

【英文标题】：XAMPP: MySQL does not start after crash

【发布时间】：2016-02-16 13:47:06

【问题描述】：

有几个关于 MySQL 在运行 XAMPP 时无法启动的问题，但不幸的是我无法从这些问题中找到解决方案。

这是我的情况： 我为 Linux 5.6.14-3 安装了 XAMPP，昨天运行它时一切正常。 今天，我再次运行 XAMPP：

/opt/lampp$ sudo ./xampp start

Starting XAMPP for Linux 5.6.14-3...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...ok.
XAMPP: Starting ProFTPD...ok.

然后我在浏览器中打开 localhost，将我带到 xampp 仪表板。在那里我点击 phpMyAdmin 菜单条目，它给了我：

Error

MySQL said: 
Cannot connect: invalid settings.

Connection for controluser as defined in your configuration failed.

phpMyAdmin tried to connect to the MySQL server, 
and the server rejected the connection. 
You should check the host, username and password 
in your configuration and make sure that they 
correspond to the information given by the 
administrator of the MySQL server.

我认为我确保控制用户拥有正确的通行证。

问题似乎是 MySQL 并没有真正启动，尽管它说“ok”（见上文）。因为，当我停止 XAMPP 时，我得到：

/opt/lampp$ sudo ./xampp stop

Stopping XAMPP for Linux 5.6.14-3...
XAMPP: Stopping Apache...ok.
XAMPP: Stopping MySQL...not running.
XAMPP: Stopping ProFTPD...ok.

查看xampp的error_log，有一个条目，看起来很可疑（虽然我不是很懂），说：

[Sun Nov 15 11:38:59.737875 2015] [mpm_prefork:notice] [pid 6217] AH00169: caught SIGTERM, shutting down 

所以，如果有人能够找到问题所在或给我提示以解决问题，我将不胜感激。已经谢谢了！

---

编辑 - 问题“已修复”（但不知道我到底做了什么）

这是 MySQL 错误日志（位于 /opt/lampp/var/mysql/[computername].err）：

2015-11-15 15:52:44 10864 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/
2015-11-15 15:52:44 140410457307008 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
2015-11-15 15:52:44 140410457307008 [Note] /opt/lampp/sbin/mysqld (mysqld 10.1.8-MariaDB) starting as process 11011 ...
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Memory barrier is not used
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using CPU crc32 instructions
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Completed initialization of buffer pool
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The log sequence numbers 3813213 and 3813213 in ibdata files do not match the log sequence number 9929741 in the ib_logfiles!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Database was not shutdown normally!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Starting crash recovery.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-15 15:52:44 140410457307008 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace bitnami_joomla/jos_content_frontpage uses space ID: 14 at filepath: ./bitnami_joomla/jos_content_frontpage.ibd. Cannot open tablespace phpmyadmin/pma__bookmark which uses space ID: 14 at filepath: ./phpmyadmin/pma__bookmark.ibd
2015-11-15 15:52:44 7fb3db6e3780  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./phpmyadmin/pma__bookmark.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
2015-11-15 15:52:44 10864 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/[computername].pid ended

第一次尝试：我备份了目录/opt/lampp/var/mysql/phpmyadmin/并添加了

innodb_force_recovery = 1

在 /opt/lampp/etc/my.conf 的末尾。再次启动 MySQL 时，这给了我同样的错误。

接下来的尝试是从目录中删除文件 pma__bookmarks.idb，这导致错误现在抱怨 pma__favorites。

最后，我删除了所有 pma__*.idb 文件，瞧！ MySQL 正在运行，我可以访问 phpMyAdmin 页面。

对我有用，但我不知道删除 pma 数据库会丢失什么？ （它们没有以任何方式恢复，看起来......）

可能是数据库文件损坏了，当我的计算机出现故障时，它们仍在运行！？

【参考方案1】：

您必须检查top 中是否存在mysqld 进程，然后尝试连接mysql 命令行客户端或查看MySQL 错误日志。有时 xampp 可能会被 MySQL 服务器混淆，例如预装操作系统。

【讨论】：

感谢您的回答，但我找不到任何正在运行的 sql 进程。既不查看顶部输出，也不查看 'ps -Al | grep -i sql' 给了我任何东西。没有其他 sql 服务正在运行...但是您让我搜索 mysql-log 并且我以某种方式找到了“修复”。查看我的编辑。

"Previous tablespace ... uses space ID ..." 通常意味着您只是混合了来自不同 MySQL 服务器的 .ibd 文件。 （例如，使用现有旧文件将一些文件复制到 datadir 中）。 InnoDB 对此非常敏感，因此您不应复制单个文件等。