当我尝试启动mysqld时，它立即崩溃了。我试图找出原因，试图将innodb_force_recovery设置为任何值，但它没有帮助。
有人会帮我理解日志吗？
FileSystemWatcher一个小细节：我试图用mysql服务启动它：
160202 16:54:21 InnoDB: Waiting for the background threads to start
160202 16:54:22 InnoDB: 5.5.37 started; log sequence number 0
160202 16:54:22 InnoDB: !!! innodb_force_recovery is set to 6 !!!
160202 16:54:22 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
160202 16:54:22 [Note] - '127.0.0.1' resolves to '127.0.0.1';
160202 16:54:22 [Note] Server socket created on IP: '127.0.0.1'.
160202 16:54:22 [Note] Event Scheduler: Loaded 0 events
160202 16:54:22 [Note] mysqld: ready for connections.
Version: '5.5.37-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
160202 16:54:31 InnoDB: Assertion failure in thread 140187534427904 in file row0sel.c line 2361
InnoDB: Failing assertion: field->col->mtype == type
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.
15:54:31 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=33554432
read_buffer_size=131072
max_used_connections=10
max_threads=1500
thread_count=10
connection_count=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 3314053 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f7ffa7cae50
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 = 7f7ff430fe60 thread_stack 0x30000
mysqld(my_print_stacktrace+0x29)[0x7f7ff94ec979]
mysqld(handle_fatal_signal+0x3d8)[0x7f7ff93d3f78]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f7ff7f2ecb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f7ff7596425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f7ff7599b8b]
mysqld(+0x5bbc6d)[0x7f7ff9584c6d]
mysqld(+0x59f052)[0x7f7ff9568052]
mysqld(+0x4b789d)[0x7f7ff948089d]
mysqld(+0x4b7f7d)[0x7f7ff9480f7d]
mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyyb+0x1c94)[0x7f7ff948da44]
mysqld(+0x34695f)[0x7f7ff930f95f]
mysqld(_ZN4JOIN8optimizeEv+0x52b)[0x7f7ff9312d0b]
mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xcd)[0x7f7ff931546d]
mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x174)[0x7f7ff931b584]
mysqld(+0x30a914)[0x7f7ff92d3914]
mysqld(_Z21mysql_execute_commandP3THD+0x12c3)[0x7f7ff92da573]
mysqld(+0x314cae)[0x7f7ff92ddcae]
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1824)[0x7f7ff92dfd34]
mysqld(_Z24do_handle_one_connectionP3THD+0x105)[0x7f7ff937ae95]
mysqld(handle_one_connection+0x50)[0x7f7ff937afb0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f7ff7f26e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f7ff76543fd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f7fb0004b70): is an invalid pointer
Connection ID (thread ID): 10
Status: NOT_KILLED
它的工作时间有点长，我甚至设法进入phpmyadmin ......然后崩溃。
编辑： 该数据库用于Wordpress网站。
当我启动mysql时，我设法有几秒的正常运行时间。在转储尝试中，似乎转储总是在进入wp_options表时停止。
这是一个innoDB表，所以她很可能是被破坏的表。 我无法修复它，我试图将其转储并重新加载......没有任何成功。 当我尝试加载转储时，会发生这种情况：
service mysql start
答案 0 :(得分：0)
好的，我终于设法解决了这个问题。 我遇到的最后一个错误（ERROR 1030（HY000））是由innodb_force_recovery仍然设置引起的。
以下是我所做的步骤：
为我工作，现在正常运行3小时，没有崩溃。