重启后MySQL不会启动。 退出信号11

昨晚我正在做一个服务器维护，需要重新启动数据库。 configuration没有改变。

目前的设置如下：

主（server1） – 主（server2）和从（server0）

MySQL版本：mysql-5.5.32

• 从可能破解的服务器上取数据库
• 使用S3作为数据访问服务器的优点和缺点是什么？
• 转移到Azure数据库服务器然后直接安装它的优点是什么？
• OpenShift允许永久的外部访问PostgreSQL
• 保护Web服务器和数据库

server0和server1启动罚款后重新启动，但是当我尝试启动server0它崩溃信号11错误：

这里是日志输出：

140604 03:10:08 mysqld_safe Starting mysqld daemon with databases from /opt/mysql/mysql_data 140604 3:10:08 [Note] Plugin 'FEDERATED' is disabled. 140604 3:10:08 InnoDB: The InnoDB memory heap is disabled 140604 3:10:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins 140604 3:10:08 InnoDB: Compressed tables use zlib 1.2.3 140604 3:10:08 InnoDB: Using Linux native AIO 140604 3:10:08 InnoDB: Initializing buffer pool, size = 32.0G 140604 3:10:10 InnoDB: Completed initialization of buffer pool 02:10:10 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=67108864 read_buffer_size=8388608 max_used_connections=0 max_threads=2000 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 = 49240442 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/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x7a2825] /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x403)[0x670b43] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7f1c2db0e030] /usr/local/mysql/bin/mysqld[0x93ec38] /usr/local/mysql/bin/mysqld[0x8328d2] /usr/local/mysql/bin/mysqld[0x861511] /usr/local/mysql/bin/mysqld[0x7f302f] /usr/local/mysql/bin/mysqld[0x7c40dd] /usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x673948] /usr/local/mysql/bin/mysqld[0x58307a] /usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb5d)[0x586c9d] /usr/local/mysql/bin/mysqld[0x507bab] /usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x3e2)[0x508772] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f1c2ccccead] /usr/local/mysql/bin/mysqld[0x4fe17a] 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. 140604 03:10:10 mysqld_safe mysqld from pid file /opt/mysql/mysql_data/odb2.pid ended 

之后，我用innodb_force_recovery = 1启动mysql，服务器启动正常。

查看文档：

* 1（SRV_FORCE_IGNORE_CORRUPT）即使检测到损坏的页面，也让服务器运行。 尝试使SELECT * FROM tbl_name跳过损坏的索引logging和页面，这有助于转储表。*

所以我的下一步是在所有数据库上运行mysqlcheck，但没有发现错误。

任何想法如何使服务器的生命？ 我有一个所有数据库（〜300GB）的备份，但恢复它会花费相当多的时间，如果可能的话，我想避免