MySQL崩溃了，无法启动

我们的生产mysql服务器刚刚崩溃，无法恢复。出现段错误。我尝试重新启动，只是不知道还要尝试什么。这是堆栈跟踪：

140502 14:13:05 [注意]插件“ FEDERATED”已禁用。
InnoDB：日志扫描已通过检查点lsn 108 1057948207
140502 14:13:06 InnoDB：数据库未正常关闭！
InnoDB：开始崩溃恢复。
InnoDB：从.ibd文件读取表空间信息...
InnoDB：从doublewrite还原可能的半写数据页
InnoDB：缓冲区...
InnoDB：正在执行恢复：扫描到日志序列号108 1058059648
InnoDB：1个必须回滚或清理的事务
InnoDB：总共15行操作要撤消
InnoDB：Trx ID计数器为0 562485504
140502 14:13:06 InnoDB：正在将一批日志记录应用于数据库...
InnoDB：进度百分比：4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB：批处理申请完成
InnoDB：从后台开始回退未提交的事务
140502 14:13:06 InnoDB：回退ID为0 562485192的trx，需要撤消15行
140502 14:13:06 InnoDB：已启动; 日志序列号108 1058059648
140502 14:13:06 InnoDB：文件../../../storage/innobase/fsp/fsp0fsp.c行1593中的线程1873206128断言失败
InnoDB：失败断言：frag_n_used> 0
InnoDB：我们有意生成一个内存陷阱。
InnoDB：将详细的错误报告提交到http://bugs.mysql.com。
InnoDB：如果您反复声明失败或崩溃，甚至
InnoDB：mysqld启动后，可能立即
InnoDB：InnoDB表空间中的损坏。请参阅
InnoDB：http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB：关于强制恢复。
140502 14:13:06-mysqld收到信号6;
这可能是因为您遇到了错误。这个二进制也有可能
或与之链接的某个库已损坏，构建不当，
或配置错误。该错误也可能是由硬件故障引起的。
我们将尽力收集一些有助于诊断的信息
问题，但是由于我们已经崩溃了，所以肯定有问题
这可能会失败。

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
threads_connected = 0
mysqld可能用尽 
key_buffer_size +（read_buffer_size + sort_buffer_size）* max_threads = 345919 K
内存字节
希望没事；如果不是，则减少方程中的一些变量。

thd：0x0
尝试回溯。您可以使用以下信息来查找
mysqld在哪里死亡。如果此后您没有看到任何消息，则说明发生了某些情况
严重错误...
stack_bottom =（nil）thread_stack 0x30000
140502 14:13:06 [Note]事件计划程序：已加载0个事件
140502 14:13:06 [注意] / usr / sbin / mysqld：准备连接。
版本：'5.1.41-3ubuntu12.10'套接字：'/var/run/mysqld/mysqld.sock'端口：3306（Ubuntu）
/ usr / sbin / mysqld（my_print_stacktrace + 0x2d）[0xb7579cbd]
/ usr / sbin / mysqld（handle_segfault + 0x494）[0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182）[0xb6cc5a82]
/ usr / sbin / mysqld（+ 0x4867e9）[0xb74647e9]
/ usr / sbin / mysqld（btr_page_free_low + 0x122）[0xb74f1622]
/ usr / sbin / mysqld（btr_compress + 0x684）[0xb74f4ca4]
/ usr / sbin / mysqld（btr_cur_compress_if_useful + 0xe7）[0xb74284e7]
/ usr / sbin / mysqld（btr_cur_pessimistic_delete + 0x332）[0xb7429e72]
/ usr / sbin / mysqld（btr_node_ptr_delete + 0x82）[0xb74f4012]
/ usr / sbin / mysqld（btr_discard_page + 0x175）[0xb74f41e5]
/ usr / sbin / mysqld（btr_cur_pessimistic_delete + 0x3e8）[0xb7429f28]
/ usr / sbin / mysqld（+ 0x526197）[0xb7504197]
/ usr / sbin / mysqld（row_undo_ins + 0x1b1）[0xb7504771]
/ usr / sbin / mysqld（row_undo_step + 0x25f）[0xb74c210f]
/ usr / sbin / mysqld（que_run_threads + 0x58a）[0xb74a31da]
/ usr / sbin / mysqld（trx_rollback_or_clean_all_without_sess + 0x3e3）[0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e）[0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e）[0xb6d65a4e]
http://dev.mysql.com/doc/mysql/en/crashing.html上的手册页包含
有助于您找出导致崩溃的原因的信息。

有什么建议吗？

哎哟。

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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

检查建议的网页：http : //dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html。

基本上，尝试以恢复模式启动MySQL服务器并备份崩溃的表。

编辑您的/etc/my.cnf并添加：

 innodb_force_recovery = 1

...以查看是否可以进入数据库并获取数据/查找损坏的表。

通常，发生这种情况时需要重新构建（至少要重建一两个损坏的表）。

从http://chepri.com/mysql-innodb-corruption-and-recovery/中：

1. 停止mysqld（service mysql stop）。
2. 后备 /var/lib/mysql/ib*

3. 将以下行添加到/etc/my.cnf：

   innodb_force_recovery = 1
   

   （他们建议4，但最好从1开始，如果不开始则增加）

4. 重新启动mysqld（service mysql start）。

5. 转储所有表： mysqldump -A > dump.sql
6. 删除所有需要恢复的数据库。
7. 停止mysqld（service mysql stop）。
8. 去掉 /var/lib/mysql/ib*
9. 注释掉innodb_force_recovery在/etc/my.cnf
10. 重新启动mysqld。查看mysql错误日志。默认情况下，应该/var/lib/mysql/server/hostname.com.err查看它如何创建新ib*文件。
11. 从转储还原数据库： mysql < dump.sql

我在使用mysql：5.7 docker image时遇到同样的错误。主要错误是试图创建默认存在的root用户。更多信息：https : //github.com/docker-library/mysql/issues/129

如以上链接中所述，解决方案是在启动docker映像时不要在环境变量中设置MYSQL_USER和MYSQL_PASSWORD。

这是我在Laravel Homestead中发生的（在运行Mac OS Sierra 10.12.4（16E195）的内核崩溃后出现流浪汉：

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

尽管没有修复选项对我有用，但您可以尝试以下资源：

https://dev.mysql.com/doc/refman/5.7/zh-CN/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/zh-CN/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

我尝试在mysql config中添加强制恢复（从1开始，然后逐渐提高，因为据称较高的数字可能会导致永久性损坏）：

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

在另一个窗口中，运行：

tail -f /var/log/mysql/error.log

然后尝试在启用各种选项的情况下重新启动mysqld：

sudo /etc/init.d/mysql restart

如果超时，则可以使用以下命令强制重启mysql进程：

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

如果有效，日志将显示如下内容：

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

如果失败，日志将显示如下内容：

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

当情况变得更糟时，我尝试删除可能已损坏的数据库：

sudo ls -alt /var/lib/mysql

原来，我一直在使用的数据库是列表顶部最近修改的数据库。幸运的是，从那天起我就对其进行了SQL转储，因此能够将其删除：

sudo rm -rf /var/lib/mysql/<database_name>

我留下了所有其他文件，并且mysql仍然能够启动。

更新：请确保innodb_force_recovery = 1一旦mysql重新工作就禁用它，否则在尝试修改数据库和表时会出现错误。

然后，我使用Sequel Pro重新创建了数据库，重新导入了数据，并且能够继续进行而不必丢弃其他项目中的所有数据库。

展望未来，我必须假设任何mysql数据库都可能损坏，并尝试保留每日备份，并将数据库重新创建脚本记录或编码到我的持续集成工具中。