Mysql崩溃,不会启动

我们的生产mysql服务器刚刚崩溃,不会回来。 这是一个段错误。 我尝试重新启动,只是不知道还有什么要尝试。 这里是堆栈跟踪:

 140502 14:13:05 [注]插件'FEDERATED'被禁用。
 InnoDB:日志扫描通过检查点lsn 108 1057948207
 InnoDB:数据库没有正常closures!
 InnoDB:启动崩溃恢复。
 InnoDB:从.ibd文件读取表空间信息...
 InnoDB:从双写中恢复可能的半写数据页面
 InnoDB:缓冲区...
 InnoDB:进行恢复:扫描到日志序号108 1058059648
 InnoDB:1个必须回滚或清理的事务
 InnoDB:共有15行操作来撤消
 InnoDB:Trx id计数器是0 562485504
 140502 14:13:06 InnoDB:开始一批日志logging应用到数据库...
 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:回滚TRX ID为562485192,15行撤消
 140502 14:13:06 InnoDB:开始; 日志序号108 1058059648
 140502 14:13:06 InnoDB:线程1873206128中的断言失败../../../storage/innobase/fsp/fsp0fsp.c行1593
 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;
这可能是因为你遇到了一个错误。 这个二进制也有可能
或者其中一个链接的图书馆是腐败的,build造不当的,
或错误configuration。 这个错误也可能是由硬件故障造成的。
我们将尽我们所能来收集一些有希望帮助诊断的信息
这个问题,但是既然我们已经崩溃了,那肯定是错的
这可能会失败。

的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
内存字节
希望没关系; 如果不是,则减less方程中的一些variables。

 thd:0x0
试图回溯。 您可以使用以下信息来了解
 mysqld死了。 如果在这之后你看不到任何信息
非常错误
 stack_bottom =(nil)thread_stack 0x30000
 140502 14:13:06 [Note] Event Scheduler:加载了0个事件
 140502 14:13:06 [注] / usr / sbin / mysqld:准备连接。
版本:'5.1.41-3ubuntu12.10'socket:'/var/run/mysqld/mysqld.sock'port: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手册页包含
信息应该可以帮助你找出造成这次事故的原因。

任何build议?

哎哟。

 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

基本上,做一个你的坠毁表的备份。 编辑你的/etc/my.cnf然后添加

  innodb_force_recovery = 1 

看看你是否可以进入你的数据库,并得到你的数据/find损坏的表通常当这种情况发生时,它的重build(至less是一个或两个损坏的表)

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

  1. 停止mysqld。
  2. 备份/ var / lib / mysql / ib *
  3. 将以下行添加到/etc/my.cnf

innodb_force_recovery = 1(他们build议4,但最好从1开始,如果不启动则增加)

  1. 重新启动mysqld。
  2. 转储所有表:#mysqldump -A> dump.sql
  3. 删除所有需要恢复的数据库。
  4. 停止mysqld。
  5. 删除/ var / lib / mysql / ib *
  6. 在/etc/my.cnf中注释掉innodb_force_recovery
  7. 重新启动mysqld。 看看mysql错误日志。 默认情况下,它应该是/var/lib/mysql/server/hostname.com.err,看看它是如何创build新的ib *文件的。
  8. 从转储中恢复数据库:mysql <dump.sql

这发生在我在Laravel Homestead(stream氓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/en/forcing-innodb-recovery.html

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

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

我尝试添加强制恢复到MySQLconfiguration(从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

事实certificate,我一直在研究的数据库是名单上最近修改的数据库。 幸运的是,我从那天起为它做了一个SQL转储,所以能够删除它:

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

我离开了所有其他的文件,而且mysql能够启动。

更新:一旦mysql正在工作,一定要禁用innodb_force_recovery = 1 ,否则当你尝试修改数据库和表时你会得到错误。

然后,我用Sequel Pro重新创build数据库,重新导入我的数据,并能够继续前进,而不必从我的其他项目中丢弃所有的数据库。

outlook未来,我必须假设任何mysql数据库都可能被损坏,并尝试保持每日备份,并将数据库重新创build脚本logging或编码到我的持续集成工具中。