数据库在打开二进制日志的情况下，掉电重启之后在恢复数据库时出了问题，然后就起不起来了，各位帮忙看一下啊~~

Oct 11 14:06:49 guoyu mysqld_safe[3802]: started
Oct 11 14:06:49 guoyu mysqld[3810]: 101011 14:06:49 InnoDB: Database was not shut down normally!
Oct 11 14:06:49 guoyu mysqld[3810]: InnoDB: Starting crash recovery.
Oct 11 14:06:49 guoyu mysqld[3810]: InnoDB: Reading tablespace information from the .ibd files...
Oct 11 14:06:49 guoyu mysqld[3810]: InnoDB: Restoring possible half-written data pages from the doublewrite
Oct 11 14:06:49 guoyu mysqld[3810]: InnoDB: buffer...
Oct 11 14:06:50 guoyu kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 11 14:06:50 guoyu kernel: ata2.00: BMDMA stat 0x25
Oct 11 14:06:50 guoyu kernel: ata2.00: cmd c8/00:08:71:f2:96/00:00:00:00:00/e1 tag 0 dma 4096 in
Oct 11 14:06:50 guoyu kernel: res 51/40:00:71:f2:96/00:00:00:00:00/e1 Emask 0x9 (media error)
Oct 11 14:06:50 guoyu kernel: ata2.00: status: { DRDY ERR }
Oct 11 14:06:50 guoyu kernel: ata2.00: error: { UNC }
Oct 11 14:06:50 guoyu kernel: ata2.00: configured for UDMA/133
Oct 11 14:06:50 guoyu kernel: ata2: EH complete
Oct 11 14:06:51 guoyu kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 11 14:06:51 guoyu kernel: ata2.00: BMDMA stat 0x25
Oct 11 14:06:51 guoyu kernel: ata2.00: cmd c8/00:08:71:f2:96/00:00:00:00:00/e1 tag 0 dma 4096 in
Oct 11 14:06:51 guoyu kernel: res 51/40:00:71:f2:96/00:00:00:00:00/e1 Emask 0x9 (media error)
Oct 11 14:06:51 guoyu kernel: ata2.00: status: { DRDY ERR }
Oct 11 14:06:51 guoyu kernel: ata2.00: error: { UNC }
Oct 11 14:06:51 guoyu kernel: ata2.00: configured for UDMA/133
Oct 11 14:06:51 guoyu kernel: ata2: EH complete
Oct 11 14:06:52 guoyu kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 11 14:06:52 guoyu kernel: ata2.00: BMDMA stat 0x25
Oct 11 14:06:52 guoyu kernel: ata2.00: cmd c8/00:08:71:f2:96/00:00:00:00:00/e1 tag 0 dma 4096 in
Oct 11 14:06:52 guoyu kernel: res 51/40:00:71:f2:96/00:00:00:00:00/e1 Emask 0x9 (media error)
Oct 11 14:06:52 guoyu kernel: ata2.00: status: { DRDY ERR }
Oct 11 14:06:52 guoyu kernel: ata2.00: error: { UNC }
Oct 11 14:06:52 guoyu kernel: ata2.00: configured for UDMA/133
Oct 11 14:06:52 guoyu kernel: ata2: EH complete
Oct 11 14:06:53 guoyu kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 11 14:06:53 guoyu kernel: ata2.00: BMDMA stat 0x25
Oct 11 14:06:53 guoyu kernel: ata2.00: cmd c8/00:08:71:f2:96/00:00:00:00:00/e1 tag 0 dma 4096 in
Oct 11 14:06:53 guoyu kernel: res 51/40:00:71:f2:96/00:00:00:00:00/e1 Emask 0x9 (media error)
Oct 11 14:06:53 guoyu kernel: ata2.00: status: { DRDY ERR }
Oct 11 14:06:53 guoyu kernel: ata2.00: error: { UNC }
Oct 11 14:06:53 guoyu kernel: ata2.00: configured for UDMA/133Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: Error: tried to read 16384 bytes at offset 1 1912930304.
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: Was only able to read 8192.
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: Fatal error: cannot read from file. OS error number 17.
Oct 11 14:06:54 guoyu mysqld[3342]: 101011 14:06:54InnoDB: Assertion failure in thread 3083036352 in file os0file.c line 2176
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: We intentionally generate a memory trap.
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: If you get repeated assertion failures or crashes, even
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: immediately after the mysqld startup, there may be
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Oct 11 14:06:54 guoyu mysqld[3342]: InnoDB: about forcing recovery.
Oct 11 14:06:54 guoyu mysqld[3342]: mysqld got signal 11;
Oct 11 14:06:54 guoyu mysqld[3342]: This could be because you hit a bug. It is also possible that this binary
Oct 11 14:06:54 guoyu mysqld[3342]: or one of the libraries it was linked against is corrupt, improperly built,
Oct 11 14:06:54 guoyu mysqld[3342]: or misconfigured. This error can also be caused by malfunctioning hardware.
Oct 11 14:06:54 guoyu mysqld[3342]: We will try our best to scrape up some info that will hopefully help diagnose
Oct 11 14:06:54 guoyu mysqld[3342]: the problem, but since we have already crashed, something is definitely wrong
Oct 11 14:06:54 guoyu mysqld[3342]: and this may fail.
Oct 11 14:06:54 guoyu mysqld[3342]:
Oct 11 14:06:54 guoyu mysqld[3342]: key_buffer_size=0
Oct 11 14:06:54 guoyu mysqld[3342]: read_buffer_size=131072
Oct 11 14:06:54 guoyu mysqld[3342]: max_used_connections=0
Oct 11 14:06:54 guoyu mysqld[3342]: max_connections=10000
Oct 11 14:06:54 guoyu mysqld[3342]: threads_connected=0
Oct 11 14:06:54 guoyu mysqld[3342]: It is possible that mysqld could use up to
Oct 11 14:06:54 guoyu mysqld[3342]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 788401 K
Oct 11 14:06:54 guoyu mysqld[3342]: bytes of memory
Oct 11 14:06:54 guoyu mysqld[3342]: Hope that's ok; if not, decrease some variables in the equation.
Oct 11 14:06:54 guoyu mysqld[3342]:
Oct 11 14:06:54 guoyu mysqld[3342]: thd=(nil)
Oct 11 14:06:54 guoyu mysqld[3342]: Attempting backtrace. You can use the following information to find out
Oct 11 14:06:54 guoyu mysqld[3342]: where mysqld died. If you see no messages after this, something went
Oct 11 14:06:54 guoyu mysqld[3342]: terribly wrong...
Oct 11 14:06:54 guoyu mysqld[3342]: Cannot determine thread, fp=0xbfe15308, backtrace may not be correct.
Oct 11 14:06:54 guoyu mysqld[3342]: Stack range sanity check OK, backtrace follows:
Oct 11 14:06:54 guoyu mysqld[3342]: 0x81c0759
Oct 11 14:06:54 guoyu mysqld[3342]: 0x83e07f5
Oct 11 14:06:54 guoyu mysqld[3342]: 0x83aab34
Oct 11 14:06:54 guoyu mysqld[3342]: 0x836f0d5
Oct 11 14:06:54 guoyu mysqld[3342]: 0x8395caf
Oct 11 14:06:54 guoyu mysqld[3342]: 0x82f1dd9
Oct 11 14:06:54 guoyu mysqld[3342]: 0x82780a7
Oct 11 14:06:54 guoyu mysqld[3342]: 0x826d852
Oct 11 14:06:54 guoyu mysqld[3342]: 0x81bf845
Oct 11 14:06:54 guoyu mysqld[3342]: 0x81c2e35
Oct 11 14:06:54 guoyu mysqld[3342]: 0xb7c4cea8
Oct 11 14:06:54 guoyu mysqld[3342]: 0x8139e91
Oct 11 14:06:54 guoyu mysqld[3342]: New value of fp=(nil) failed sanity check, terminating stack trace!
Oct 11 14:06:54 guoyu mysqld[3342]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Oct 11 14:06:54 guoyu mysqld[3342]: stack trace is much more helpful in diagnosing the problem, so please do
Oct 11 14:06:54 guoyu mysqld[3342]: resolve it
Oct 11 14:06:54 guoyu mysqld[3342]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Oct 11 14:06:54 guoyu mysqld[3342]: information that should help you find out what is causing the crash.
Oct 11 14:06:54 guoyu mysqld_safe[3388]: ended
Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]:
Oct 11 14:09:01 guoyu /USR/SBIN/CRON[3489]: (root) CMD ( [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)

解决方案 »

  1.   

    Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
    Oct 11 14:07:03 guoyu /etc/init.d/mysql[3480]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!看看有么？
      

  2.   


    突然发现，二进制日志不是指ib_logfile0，ib_logfile1吗？我以为这个就是二进制日志呢~~
    那怎么开二进制日志啊，怎么能查看自己开没开二进制日志？
      

  3.   

    Oct 11 14:06:54 guoyu mysqld[3342]: mysqld got signal 11;应该是碰到mysql的bug了。ib_logfile0/1 只有innodb的log。二进制日志是bin log，如果是开着的话，mysql的data或log文件夹里会有以mysql-bin为前缀的文件（除非bin_log设置为其他值），看看/etc/my.cnf的设置。如果数据丢失一些没有关系的话，可以试试把ib_logfile0和ib_logfile1移走，然后再试试重启服务器。
      

  4.   

    http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html先停止mysql,备份所有数据,然后设置为恢复模式,导出数据!