现在的位置: 首页Mysql>正文
服务器断电后,mysql无法启动
2014年10月21日 Mysql 暂无评论 ⁄ 被围观 3,594 view+

mysql报错信息如下:

mysqld got signal 11141021 10:09:24 mysqld_safe Starting mysqld daemon with databases from var/lib/mysql
141021 10:09:24 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
141021 10:09:24  InnoDB: Initializing buffer pool, size = 8.0M
141021 10:09:24  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 13 2788793592
141021 10:09:24  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 13 2789029991
141021 10:09:25  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 02:09:25 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=402653184
read_buffer_size=524288
max_used_connections=0
max_threads=4096
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4630112 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x29) [0x84f539]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a3713]
/lib64bpthread.so.0(+0xf500) [0x7ff221355500]
/usr/libexec/mysqld(page_cur_insert_rec_low+0x288) [0x798a28]
/usr/libexec/mysqld(page_cur_parse_insert_rec+0x4eb) [0x7995cb]
/usr/libexec/mysqld() [0x786a3d]
/usr/libexec/mysqld(recv_recover_page+0x34f) [0x7884ff]
/usr/libexec/mysqld(buf_page_io_complete+0x548) [0x749ba8]
/usr/libexec/mysqld(fil_aio_wait+0xfa) [0x761aca]
/usr/libexec/mysqld() [0x7c79a0]
/lib64/libpthread.so.0(+0x7851) [0x7ff22134d851]
/lib64/libc.so.6(clone+0x6d) [0x7ff21fa9a90d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
141021 10:09:25 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

解决方法:

[mysqld]
innodb_force_recovery = 4

innodb_force_recovery参数解释:

innodb_force_recovery影响整个InnoDB存储引擎的恢复状况,默认值为0,表示当需要恢复时执行所有的恢复操作。
当不能进行有效的恢复操作时,mysql有可能无法启动,并记录下错误日志。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

a.强制启动后,此时数据库数据只能查看不能修改,不能插入。

b.然后执行mysqldump命令将数据导出。

c.删除并重建数据库,

d.还原innodb_force_recovery默认值

d.导入数据。

间接地解决了问题。顺便求直接恢复数据方法。

给我留言

留言无头像?


×
腾讯微博