web-dev-qa-db-ja.com

InnoDBテーブルSELECTがERROR 2006（HY000）を返す：MySQLサーバーが停止した（停電後）

このサーバーはCentOS 6.0、MySQL 5.5.21を実行する仮想マシンです

devSystemという名前のデータベースがあります。内部にはInnoDBテーブルがあります。次のコマンドを実行すると、エラーERROR 2006 (HY000): MySQL server has gone awayが発生します。私は以前にInnoDBを広範囲に使用したことがないため、この種の問題はまだ発生していません。 MyISAMを使用して浮上していないため、これはInnoDBに固有であるとしか想定できません。とにかく、実行しようとしたコマンドは次のとおりです。

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に存在するテーブルdevSystemからSELECTしようとしています

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テーブルもある2番目のデータベースを試しました

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

これにより、テーブルが正しく出力されます。このため、特にdevSystemの問題だと思います。

私はここで検索を試みましたが、他の同様のクエリが役に立たないようです、これを解決するのに役立つ提案/アドバイスはありますか？これまでのところ、私の朝は無駄になっています！

現在のオプションは、データベースを削除してやり直すことです（ただし、かなりの量の作業が失われます。ほぼ最新のデータベース設計ですが、これまでに生成されたデータのバックアップはありません）。

update 1innodb_force_recovery = 6をmy.cnfに追加すると、SHOW TABLE STATUSが正常に実行され、<= 5の値でも引き続き上記のエラー。このフラグSELECT * FROM basketsは機能しますが、1つのテーブルが特に問題を引き起こしている1つのテーブルであることを示すエラーが返されますか？

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が言ったように）。私が行った限り、Percona Recovery Toolsに関するDTestの提案に従いましたが、データが破損しているため、特定のテーブルのibdata1ファイルからデータを抽出できませんでした。

最後に、RolandoMySQLDBAの回答を使用して、次のことを行いました

  1. ここに続く指示 https://stackoverflow.com/questions/3927690/howto-clean-a-mysql-innodb-storage-engine/4056261#4056261 クラッシュしたデータベースを除外
  2. innodb_force_recovery = 6を使用して、クラッシュしたテーブルを含むデータベースから、クラッシュしていないすべてのテーブルデータを取得しました
  3. MySQlをシャットダウンし、innodb_force_recovery = 6を削除し、ibdata/iblogファイルを削除しました（ステップ1のリンクに詳細が記載されています）
  4. MySQLを起動し、ダンプされたデータをロード
  5. 設計ファイルから不良テーブルを再作成
  6. 手動で再入力されたデータ

もちろん、これは影響を受けるテーブルからの完全なデータ損失を意味しましたが、innodb_file_per_tableを追加すると、これが再発した場合のデータ回復に役立つことを期待できます-いつか電源を切って試してみるつもりですテストデータベースでこれを再現します。

以下は、ログからのより詳細な情報です。

my.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
mysqlinnodbmysql-5.5myisam
7
Simon at My School Portal

これは奇妙に見覚えがあります。

これは、私のWebホスティングクライアントのDBサーバーの1つで発生することを確認しました。 SHOW CREATE TABLEを使用しても、アクセスするたびにmysqldをクラッシュさせる特定のテーブルがありました。

この問題は、データディクショナリの破損が原因です。それを修正する方法は本当にありません。 .ibdファイル内のtablespace_idの変更を試みることもできますが、頭痛の種は、ibdata1の内部にあるtablespace_idリストを見つけることです。

元のInnoDBテーブルと同じデータベースに同じ名前のMyISAMテーブルを作成しても、tablespace_idはすでにテーブル名に関連付けられているため、テーブルをInnoDBに変換できません。もちろん、これは破損した状態です。これは、ibdata1にピジョンホールがあるようなもので、探索的手術を行わないとパッチを適用できません。

破損したテーブルを格納しているデータベース以外のすべてをmysqldumpする必要がある場合があります。次に、破損したテーブルを除いて、そのデータベース内のすべてのテーブルをmysqldumpする必要があります。失敗するのはテーブルのデータディクショナリのビューであり、必ずしもテーブルのデータではないことを覚えておいてください。

すべてをクリーンアップする唯一の確実な方法は、指定したとおりにmysqldumpを実行して、mysqlをシャットダウンし、/ var/lib/mytsql/mysqlを除くすべてのDBフォルダーを削除し、ibdata1を削除し、ib_logfile0を削除し、ib_logfile1を削除し、mysqlを起動し、リロードすることです。すべてのmysqldumps。 InnoDBインフラストラクチャのクリーンアップに関する私のStackOverflowの投稿 を参照してください。

Innodb_file_per_tableを使用していないため、ibdata1内のこの破損した状態のテーブルは、戦争の犠牲として失われます。お悔やみ申し上げます。

今後の参考情報として、ここをクリックしてInnoDBとその内部構造の 芸術的概念 をご覧ください。

4
RolandoMySQLDBA

あなたは最悪のケースを打つように思われます：復元するためのバックアップがない（おそらくはるかに速い）破損したinnodbテーブルスペース。

Perconaが提供する 無料のinnodb回復ツール があり、 このブログ を使用して、バックアップなしで破損したデータを復元する方法を説明しています。

この非常に重要な警告があります：

行の削除からデータベースの停止までの時間は重要です。ページが再利用された場合、データを回復することはできません。

残念ながら、破損したinnodbを修復する経験は、私が個人的に行った経験よりもはるかに多くなります。

2
Derek Downey