有人能帮我吗？我担心会丢失数据。MySQL 停止运行，当我尝试重新启动或启动它时，却无法启动。当我查看日志文件时，我看到以下信息：
150712 6:36:15 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
150712 6:36:15 [Note] Plugin 'FEDERATED' is disabled.
150712 6:36:15 InnoDB: The InnoDB memory heap is disabled
150712 6:36:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150712 6:36:15 InnoDB: Compressed tables use zlib 1.2.8
150712 6:36:15 InnoDB: Using Linux native AIO
150712 6:36:15 InnoDB: Initializing buffer pool, size = 4.0G
150712 6:36:15 InnoDB: Completed initialization of buffer pool
150712 6:36:15 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 14001211870
150712 6:36:15 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 14001212249
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 3133200
150712 6:36:15 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
150712 6:36:15 InnoDB: Rolling back trx with id 313307B, 1 rows to undo
150712 6:36:15 InnoDB: Waiting for the background threads to start
150712 6:36:15 InnoDB: Assertion failure in thread 140519574923008 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:36:15 UTC - mysqld got signal 6 ;
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=16777216
read_buffer_size=4194304
max_used_connections=0
max_threads=1000
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 = 6171907 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x7fce853e8c80]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x7fce852d2f15]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fce84063340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7fce836bacc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fce836be0d8]
/usr/sbin/mysqld(+0x274ab1)[0x7fce8516cab1]
/usr/sbin/mysqld(+0x60d818)[0x7fce85505818]
/usr/sbin/mysqld(+0x5982c9)[0x7fce854902c9]
/usr/sbin/mysqld(+0x5ac63a)[0x7fce854a463a]
/usr/sbin/mysqld(+0x5a4de4)[0x7fce8549cde4]
/usr/sbin/mysqld(+0x5a5f90)[0x7fce8549df90]
/usr/sbin/mysqld(+0x5a0a7f)[0x7fce85498a7f]
/usr/sbin/mysqld(+0x64e76a)[0x7fce8554676a]
/usr/sbin/mysqld(+0x64edf4)[0x7fce85546df4]
/usr/sbin/mysqld(+0x59f323)[0x7fce85497323]
/usr/sbin/mysqld(+0x59f89e)[0x7fce8549789e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fce8405b182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fce8377e47d]
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.
我已经在互联网上搜索可能的解决方案，但我担心我会读到错误的文章。
有人能建议一下最好的、最先要做的事情是什么吗？
答案1
第一和最好的：
该错误也可能是由硬件故障引起的。
在某个地方启动一个新系统并尝试使用它使您的数据库联机。您可以将 mysql 目录树的全部内容复制到新目录树的顶部。
如果那也失败了。
InnoDB：断言失败：addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB：我们故意生成内存陷阱。InnoDB
：向以下地址提交详细的错误报告：http://bugs.mysql.com。
您应该提交一个错误报告。
InnoDB：如果您反复出现断言失败或崩溃，即使是
在 mysqld 启动后立即出现，也可能是
InnoDB：InnoDB 表空间中存在损坏。请参阅
InnoDB：http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB：关于强制恢复。
这似乎也是个不错的建议。
这个二进制文件或它所链接的某个库也可能已损坏，
您可以使用和的内容来验证二进制校验/var/lib/dpkg/info/*.md5sums和md5sum公用事业
手册页位于http://dev.mysql.com/doc/mysql/en/crashing.html包含可帮助您找出导致崩溃的原因的信息。
更多合理的建议。
我也会去获取我的备份。
答案2
如果你无法修复该问题，并且你希望恢复 innodb 表的数据，那么你可以使用 percona 工具包（https://www.percona.com/software/mysql-innodb-data-recovery-tools）。
文档非常好，工具也很好用。
问候。