InnoDB 表 SELECT 返回 ERROR 2006 (HY000): MySQL 服务器已消失（停电后）

Question

此服务器是一台运行 CentOS 6.0、MySQL 5.5.21 的虚拟机

有一个名为devSystem. 里面有 InnoDB 表。运行以下命令会导致错误ERROR 2006 (HY000): MySQL server has gone away。我以前没有广泛使用 InnoDB，所以还没有遇到过这种类型的问题。我只能假设它特定于 InnoDB，因为它没有使用 MyISAM 出现。无论如何，我尝试运行的命令如下。

mysql -u root -p
mysql> USE `devSystem`;
-- database changed
mysql> SHOW TABLES;

MySQL 客户端返回的完整错误

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
ERROR:
Can't connect to the server

现在尝试从baskets存在于的表中进行 SELECTdevSystem

mysql> select * from baskets\G
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
ERROR:
Can't connect to the server

为了比较，我尝试了第二个数据库，它在同一台服务器上也有 InnoDB 表

mysql> USE `testSystem`;
-- database changed
mysql> SHOW TABLES;

这将正确输出表格。出于这个原因，我推测这是一个devSystem特别的问题。

我试过在这里搜索，但其他类似的查询似乎没有帮助，有没有人有任何建议/建议可以帮助我解决这个问题？到目前为止，这已经浪费了我整个上午！

当前的选项似乎是删除数据库并重新开始（但是会失去大量工作。我有一个几乎最新的数据库设计，但是没有备份迄今为止生成的数据）

update 1 添加innodb_force_recovery = 6到my.cnf允许SHOW TABLE STATUS执行成功，<= 5 的值仍然导致如上所示的错误。使用此标志SELECT * FROM baskets运行，但是一张表特别返回错误仍然表明它可能是导致问题的一张表？

mysql> SELECT * FROM supplierOptionalExtras_relationships;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2013 (HY000): Lost connection to MySQL server during query

结论

最终，在对恢复文件进行了更多小时的扫描之后，我只能得出结论，我的数据丢失了（正如 RolandoMySQLDBA 所说）。为了做到这一点，我遵循了 DTest 关于 Percona 恢复工具的建议，但是数据损坏意味着这些工具无法从我的ibdata1文件中提取特定表的数据。

最后我使用了 RolandoMySQLDBA 的回答并做了以下事情

1. 遵循此处的说明/sf/ask/274938331/#4056261不包括崩溃的数据库
2. 用于innodb_force_recovery = 6从崩溃表的数据库中获取所有未崩溃的表数据
3. 关闭 MySQl，删除innodb_force_recovery = 6，删除 ibdata/iblog 文件（详见步骤 1 中的链接）
4. 启动 MySQL 并加载转储数据
5. 从设计文件重新创建坏表
6. 手动重新填充数据

当然，这意味着受影响表中的总数据丢失是一个问题，但是我只能希望innodb_file_per_table如果这种情况再次发生，添加将有助于数据恢复 - 我打算在某个时候关闭电源以尝试尝试在测试中重现它数据库。

---

以下是日志中的一些更详细的信息。

我的.cnf

这只是一个开发系统，所以 my.cnf 是非常基本的，实际上与默认值保持不变

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

从服务器开始到执行失败查询之前的 MySQL 日志

120302 10:57:42 [Note] /usr/libexec/mysqld: Normal shutdown

120302 10:57:42 [Note] Event Scheduler: Purging the queue. 0 events
120302 10:57:42  InnoDB: Starting shutdown...
120302 10:57:42  InnoDB: Shutdown completed; log sequence number 285938465
120302 10:57:42 [Note] /usr/libexec/mysqld: Shutdown complete

120302 10:57:42 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120302 10:57:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120302 10:57:43 [Note] Plugin 'FEDERATED' is disabled.
120302 10:57:43 InnoDB: The InnoDB memory heap is disabled
120302 10:57:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:57:43 InnoDB: Compressed tables use zlib 1.2.3
120302 10:57:43 InnoDB: Using Linux native AIO
120302 10:57:43 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:57:43 InnoDB: Completed initialization of buffer pool
120302 10:57:43 InnoDB: highest supported file format is Barracuda.
120302 10:57:43  InnoDB: Waiting for the background threads to start
120302 10:57:44 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:57:44 [Note] Event Scheduler: Loaded 0 events
120302 10:57:44 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi

查询失败后的 MySQL 日志行

120302 10:58:39  InnoDB: Assertion failure in thread 140030446421760 in file btr0btr.c line 695
InnoDB: Failing assertion: (ibool)!!page_is_comp(buf_block_get_frame(block)) == dict_table_is_comp(index->table)
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.
120302 10:58:39 - 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=8388608
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 = 338483 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x30396e0
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 = 0x7f5b61043d98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x33)[0x77b6e3]
/usr/libexec/mysqld(handle_segfault+0x465)[0x50fc35]
/lib64/libpthread.so.0[0x37a9e0f4c0]
/lib64/libc.so.6(gsignal+0x35)[0x37a9a329a5]
/lib64/libc.so.6(abort+0x175)[0x37a9a34185]
/usr/libexec/mysqld[0x82a4bb]
/usr/libexec/mysqld[0x82a60c]
/usr/libexec/mysqld[0x85d133]
/usr/libexec/mysqld[0x862207]
/usr/libexec/mysqld[0x7e37a3]
/usr/libexec/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x3d)[0x66903d]
/usr/libexec/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x537)[0x5edf67]
/usr/libexec/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0xc33)[0x54d2d3]
/usr/libexec/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x683)[0x54e043]
/usr/libexec/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTj+0x4b)[0x54e61b]
/usr/libexec/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x23)[0x5c5623]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x174f)[0x581f2f]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0xd2)[0x60e9e2]
/usr/libexec/mysqld(handle_one_connection+0x50)[0x60eaf0]
/lib64/libpthread.so.0[0x37a9e077e1]
/lib64/libc.so.6(clone+0x6d)[0x37a9ae18ed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f5b50004c20): is an invalid pointer
Connection ID (thread ID): 2
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.
120302 10:58:39 mysqld_safe Number of processes running now: 0
120302 10:58:39 mysqld_safe mysqld restarted
120302 10:58:39 [Note] Plugin 'FEDERATED' is disabled.
120302 10:58:39 InnoDB: The InnoDB memory heap is disabled
120302 10:58:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:58:39 InnoDB: Compressed tables use zlib 1.2.3
120302 10:58:39 InnoDB: Using Linux native AIO
120302 10:58:39 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:58:39 InnoDB: Completed initialization of buffer pool
120302 10:58:39 InnoDB: highest supported file format is Barracuda.
120302 10:58:39  InnoDB: Waiting for the background threads to start
120302 10:58:40 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:58:40 [Note] Event Scheduler: Loaded 0 events
120302 10:58:40 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
120302 10:58:47  InnoDB: Assertion failure in thread 140051237820160 in file btr0btr.c line 695
InnoDB: Failing assertion: (ibool)!!page_is_comp(buf_block_get_frame(block)) == dict_table_is_comp(index->table)
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.
120302 10:58:47 - 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=8388608
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 = 338483 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x231b6e0
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 = 0x7f603847cd98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x33)[0x77b6e3]
/usr/libexec/mysqld(handle_segfault+0x465)[0x50fc35]
/lib64/libpthread.so.0[0x37a9e0f4c0]
/lib64/libc.so.6(gsignal+0x35)[0x37a9a329a5]
/lib64/libc.so.6(abort+0x175)[0x37a9a34185]
/usr/libexec/mysqld[0x82a4bb]
/usr/libexec/mysqld[0x82a60c]
/usr/libexec/mysqld[0x85d133]
/usr/libexec/mysqld[0x862207]
/usr/libexec/mysqld[0x7e37a3]
/usr/libexec/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x3d)[0x66903d]
/usr/libexec/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x537)[0x5edf67]
/usr/libexec/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0xc33)[0x54d2d3]
/usr/libexec/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x683)[0x54e043]
/usr/libexec/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTj+0x4b)[0x54e61b]
/usr/libexec/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x23)[0x5c5623]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x174f)[0x581f2f]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0xd2)[0x60e9e2]
/usr/libexec/mysqld(handle_one_connection+0x50)[0x60eaf0]
/lib64/libpthread.so.0[0x37a9e077e1]
/lib64/libc.so.6(clone+0x6d)[0x37a9ae18ed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f6014004c20): is an invalid pointer
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.
120302 10:58:47 mysqld_safe Number of processes running now: 0
120302 10:58:47 mysqld_safe mysqld restarted
120302 10:58:47 [Note] Plugin 'FEDERATED' is disabled.
120302 10:58:47 InnoDB: The InnoDB memory heap is disabled
120302 10:58:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:58:47 InnoDB: Compressed tables use zlib 1.2.3
120302 10:58:47 InnoDB: Using Linux native AIO
120302 10:58:47 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:58:47 InnoDB: Completed initialization of buffer pool
120302 10:58:47 InnoDB: highest supported file format is Barracuda.
120302 10:58:47  InnoDB: Waiting for the background threads to start
120302 10:58:48 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:58:48 [Note] Event Scheduler: Loaded 0 events
120302 10:58:48 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi

Answer 1

这看起来有种奇怪的熟悉感。

我已经看到我的网络托管客户的数据库服务器之一发生了这种情况。有一个特定的表，每次访问它时都会使 mysqld 崩溃，即使使用SHOW CREATE TABLE.

该问题源于损坏的数据字典。确实没有办法纠正。您可以尝试更改 .ibd 文件中的 tablespace_id，但令人头疼的是在 ibdata1 内部查找 tablespace_id 列表。

即使您在与原始 InnoDB 表相同的数据库中创建同名的 MyISAM 表，也无法将其转换为 InnoDB，因为 tablespace_id 已经与表名关联。当然，这是一个腐败的国家。这就像 ibdata1 上有一个皮金洞，如果不进行一些探索性手术就无法修补。

您可能必须 mysqldump 除了包含损坏表的数据库之外的所有内容。然后，您必须 mysqldump 该数据库中除损坏的表之外的每个表。请记住，搞砸的是表的数据字典视图，而不一定是表的数据。

清理所有内容的唯一可靠方法是执行我刚才指定的 mysqldumps，关闭 mysql，rm -rf 除 /var/lib/mytsql/mysql 之外的所有数据库文件夹，删除 ibdata1，删除 ib_logfile0，删除 ib_logfile1，启动 mysql，重新加载所有 mysqldump。请参阅我的 StackOverflow 文章，了解如何清理 InnoDB 基础设施。

由于您没有使用 innodb_file_per_table，因此 ibdata1 中任何具有这种损坏状态的表都会作为战争伤亡而丢失。节哀顺变。

为了方便以后参考，请点击这里查看InnoDB 的艺术构思及其内部结构。