任何人都可以帮我吗？ 我害怕丢失我的数据。 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. 我已经在互联网上search可能的解决scheme，但是恐怕我会阅读错误的文章。
任何人都可以请build议什么是最好的和第一件事？
第一也是最好的：
这个错误也可能是由于硬件故障造成的。
在某个地方build立一个新的系统，并尝试使用它来联机你的数据库。 你可以把你的mysql目录树的全部内容复制到新的一个。
如果这也失败了。
InnoDB：失败断言：addr.page == FIL_NULL || addr.boffset> = FIL_PAGE_DATA
InnoDB：我们故意生成一个内存陷阱。
InnoDB：提交详细的错误报告到http://bugs.mysql.com 。
你应该提交一个错误报告。
InnoDB：如果你重复断言失败或崩溃，甚至
InnoDB：在mysqld启动之后，可能会有
InnoDB：InnoDB表空间中的损坏。 请参阅
InnoDB： http : //dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB：关于强制恢复。
这似乎也是很好的build议。
这个二进制文件或其中一个链接的库也可能是腐败的，
您可以使用/var/lib/dpkg/info/*.md5sums和md5sum实用程序的内容来validation二进制文件校验和
http://dev.mysql.com/doc/mysql/en/crashing.html上的手册页包含的信息可以帮助您找出造成崩溃的原因。
更合理的build议。
我也将达到我的备份。
以防万一你不能解决这个问题，你有innodb表你想恢复数据，你可以使用percona工具包（ https://www.percona.com/software/mysql-innodb-data-recovery-tools ） 。
该文件是相当不错的，工具很好。
问候。