我想请你帮忙。 我的mysql服务在对某个特定表的（任何类型）访问期间不断崩溃。
我在一个非常老的ubuntu版本10.04上安装了mysql。一些不幸的关机后问题就开始了。
我已经挖掘了/var/log/mysql/error.log，但没有什么真正有用的（在drop table之后登录）。
150615 22:53:01 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 20 3390045602
150615 22:53:01 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 20 3390156127
150615 22:53:01 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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
150615 22:53:02 InnoDB: Started; log sequence number 20 3390156127
InnoDB: !!! innodb_force_recovery is set to 3 !!!
150615 22:53:02 [Note] Event Scheduler: Loaded 0 events
150615 22:53:02 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.73-0ubuntu0.10.04.1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
150615 22:57:03 InnoDB: Assertion failure in thread 140699839366912 in file ../../../storage/innobase/fsp/fsp0fsp.c line 3171
InnoDB: Failing assertion: xdes_get_state(descr, mtr) == XDES_FSEG
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:57:03 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=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346534 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7ff73e7b11c0
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 = 7ff73bf1fe58 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29) [0x7ff73c5daba9]
/usr/sbin/mysqld(handle_fatal_signal+0x483) [0x7ff73c3ed1c3]
/lib/libpthread.so.0(+0xf8f0) [0x7ff73bb338f0]
/lib/libc.so.6(gsignal+0x35) [0x7ff73a5a9b65]
/lib/libc.so.6(abort+0x180) [0x7ff73a5ad6b0]
/usr/sbin/mysqld(+0x5762c0) [0x7ff73c4d92c0]
/usr/sbin/mysqld(fseg_free_step+0x1d3) [0x7ff73c4df3a3]
/usr/sbin/mysqld(btr_free_but_not_root+0xb6) [0x7ff73c55f556]
/usr/sbin/mysqld(dict_drop_index_tree+0xcb) [0x7ff73c5695fb]
/usr/sbin/mysqld(+0x5d50e1) [0x7ff73c5380e1]
/usr/sbin/mysqld(row_upd_step+0x4ca) [0x7ff73c5389ba]
/usr/sbin/mysqld(que_run_threads+0x398) [0x7ff73c516e68]
/usr/sbin/mysqld(que_eval_sql+0x166) [0x7ff73c5176c6]
/usr/sbin/mysqld(row_drop_table_for_mysql+0x3cd) [0x7ff73c52561d]
/usr/sbin/mysqld(ha_innobase::delete_table(char const*)+0x100) [0x7ff73c4999a0]
/usr/sbin/mysqld(ha_delete_table(THD*, handlerton*, char const*, char const*, char const*, bool)+0x15e) [0x7ff73c3e125e]
/usr/sbin/mysqld(+0x499671) [0x7ff73c3fc671]
/usr/sbin/mysqld(mysql_rm_table(THD*, TABLE_LIST*, char, char)+0x78) [0x7ff73c3fc9d8]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0xdb1) [0x7ff73c2eeca1]
/usr/sbin/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x3fb) [0x7ff73c2f3aab]
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x944) [0x7ff73c2f4404]
/usr/sbin/mysqld(do_command(THD*)+0xea) [0x7ff73c2f558a]
/usr/sbin/mysqld(handle_one_connection+0x23e) [0x7ff73c2e6e7e]
/lib/libpthread.so.0(+0x69ca) [0x7ff73bb2a9ca]
/lib/libc.so.6(clone+0x6d) [0x7ff73a6601cd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7ff73e80ac80): drop table db1.cache_pages
Connection ID (thread ID): 1
Status: NOT_KILLED
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.
150615 22:57:03 [Note] Plugin 'FEDERATED' is disabled.
150615 22:57:03 InnoDB: Initializing buffer pool, size = 8.0M
150615 22:57:03 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 20 3390045602
150615 22:57:03 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 20 3390156127
150615 22:57:04 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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
150615 22:57:04 InnoDB: Started; log sequence number 20 3390156127
InnoDB: !!! innodb_force_recovery is set to 3 !!!
150615 22:57:04 [Note] Event Scheduler: Loaded 0 events
150615 22:57:04 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.73-0ubuntu0.10.04.1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
正如您从日志中看到的那样我已经innodb_force_recovery = 3了，我有点害怕走得更远（ ...是的，旧备份）。这个特定的表没有重要的数据，但我真的不想删除整个数据库。
在SELECT期间，任何类型的操作（DROP，SHOW COLUMNS，USE db1 ...）也会发生崩溃。
Small UPDATE：更改表格，它的数据库也会崩溃引擎。
我的问题是如何删除该特定的表？我可以从服务器上物理删除表文件，一切都会好吗？ DB会表现得怎么样？
任何帮助都会很棒。
答案 0 :(得分：1)
我有3条一般性的建议;
当手册谈到在使用更高级别的innodb_force_recovery之前进行备份时，要对当前“已破坏”的二进制备份进行备份。数据目录很好 - 风险在于它可能会进一步破坏您的数据目录，但只要您可以返回到最初的破坏状态就可以了。
您最好的选择是使用mysqldump转储所有服务器数据，然后将其重新加载到新的数据目录中。这可能会也可能不会使服务器崩溃。希望你至少可以转储所有其他表，并且运气好的话你也可以将数据转储到这个表中，即使你无法删除它。如果您遇到mysqldump问题，请尝试使用较新的mysql版本来执行转储。确保首先按步骤（1）进行备份。
在某些情况下，即使select * from table失败，如果您尝试使用主索引选择特定行，也可能会成功。例如SELECT * FROM表WHERE id = 1 ..在这种情况下，您可以批量尝试转储主键的值，以尝试获取大部分表数据。