我们的生产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/
innodb_force_recovery = 1(他们build议4,但最好从1开始,如果不启动则增加)
这发生在我在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
我尝试添加强制恢复到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或编码到我的持续集成工具中。