web-dev-qa-db-ja.com

クエリのエラー「不明なテーブルエンジン「InnoDB」。 mysqlを再起動した後

サーバーS1にmysql DBがあります（mysqlバージョン5.1.41-3ubuntu12.7-log）。

サーバーS2（mysqlバージョン5.1.54-1ubuntu4-log）にこのDBのマスタースレーブを作成しました。

S1のDBは1つのデータファイル（ibdata）を使用していました。

DBをS2にダンプした後、innodb_file_per_table=1。これにより、すべてのテーブルが独自のibdファイルを持つようになりました。今、すべてが順調にスムーズに行きました.

S2でmysqlを再起動した後、このエラーが発生する問題に直面しました。
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDBそして、エンジンを表示しようとすると、次のようになります。

 show engines; 
 + ------------ + --------- + ------------- -------------------------------------------------- -+ -------------- + ------ + ------------ + 
 |エンジン|サポート|コメント|トランザクション| XA |セーブポイント| 
 + ------------ + --------- + ------------------- --------------------------------------------- + ---- ---------- + ------ + ------------ + 
 | MyISAM |デフォルト| MySQL 3.23以降のデフォルトエンジンと優れたパフォーマンス|いいえ|いいえ|いいえ| 
 | MRG_MYISAM |はい|同一のMyISAMテーブルのコレクション|いいえ|いいえ|いいえ| 
 |ブラックホール|はい|/dev/nullストレージエンジン（書き込んだものはすべて消えます）|いいえ|いいえ|いいえ| 
 | CSV |はい| CSVストレージエンジン|いいえ|いいえ|いいえ| 
 |メモリ|はい|ハッシュベース、メモリに保存、一時テーブルに便利|いいえ|いいえ|いいえ| 
 | FEDERATED |いいえ|連合MySQLストレージエンジン| NULL | NULL | NULL | 
 |アーカイブ|はい|アーカイブストレージエンジン|いいえ|いいえ|いいえ| 
 + ------------ + --------- + ------------------- --------------------------------------------- + ---- ---------- + ------ + ------------ +

InnoDBはリストされていません。

エラーログでは、これを見ることができます：

 InnoDB：データベースはファイルを物理的に書き込みます：待機... 
 InnoDB：作成されたログファイルを初期化できません
 InnoDB：データファイルが破損しているか、新しいデータファイルが破損していました
 InnoDB：データベースが以前に起動されたときに作成されます
 InnoDB：時間ですが、データベースはシャットダウンされませんでした
 InnoDB：通常はその後。
 111016 8:24:11 [エラー]プラグイン 'InnoDB' init関数がエラーを返しました。
 111016 8:24:11 [エラー]ストレージエンジンとしてのプラグイン 'InnoDB'の登録に失敗しました。
 111016 8:24:11 [警告] --relay-logも--relay-log-indexも使用されていません。そのため、このMySQLサーバーがスレーブとして機能し、ホスト名が変更されていると、レプリケーションが中断する可能性があります。この問題を回避するには、「-relay-log = S2-relay-bin」を使用してください。

Ib_logfilesを削除しようとしましたが、これも機能しませんでした。 ib_logfilesとibdataファイルを削除すると、innodbは正常に戻りますが、innodbテーブルにアクセスできません。 ibdata1を削除してmysqlを再起動した後

 desc article; 
エラー1146（42S02）：テーブル 'MyDb.article'は存在しません

My.cnfの私のinnodb構成は次のとおりです。

innodb_file_per_table=1  
innodb_flush_method=O_DIRECT  
innodb_log_file_size=1G  
innodb_buffer_pool_size=4G  
innodb_data_file_path=ibdata1:10M:autoextend  
innodb_buffer_pool_size = 384M  
innodb_log_file_size=5M  
innodb_lock_wait_timeout = 18000

テーブルはありますが!!

誰かが以前にそのような問題に直面したことがありますか？

どんなアイデアでも大歓迎です

ありがとう

mysqlreplicationinnodb
6
Alaa

あなたにとても悪い知らせがあります。

Ibdata1ファイルを削除してはなりません。理由は次のとおりです。

ibdata1には、4つのタイプの情報が含まれています。

  • テーブルのメタデータ
  • MVCCデータ
  • データページ（innodb_file_per_tableが有効な場合）
  • インデックスページ（innodb_file_per_tableが有効な場合）

作成された各InnoDBテーブルには、いくつかの自動インクリメントメタデータ機能を介して各ibdファイルに数値IDが割り当てられています。その内部テーブルスペースID（ITSID）は.ibdファイルに埋め込まれています。その数は、維持されているITSIDのリストに照らしてチェックされます。

私もいくつかの悪いニュースとともにあなたにとても良いニュースを持っています。

Ibdata1を再構築して正しいITSIDを設定することは可能ですが、それを行うには手間がかかります。私は個人的に一人で手順を行ったわけではありませんが、雇用主のWebホスティングでクライアントがこれを行うのを支援しました。私たちはこれを一緒に考え出しましたが、クライアントがibdata1をホースしたので、私は彼にほとんどの仕事をさせました（30のInnoDBテーブル）。

とにかく、ここではDBA StackExchangeで作成した過去の投稿です。根本的な原因がITSIDの混同であるという別の質問に答えました。

追跡を正しく行うには、 これはITSIDを参照して何をすべきか、およびibdata1をマッサージして.ibdファイル内に含まれるITSIDの存在を確認する方法を説明する記事です 。

ITSIDを使用してゲームをプレイする以外に、.ibdファイルを回復するための迅速で汚い方法はありません。

UPDATE 2011-10-17 06:19 EDT

これがあなたの質問からのあなたの元のinnodb設定です：

innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M
innodb_lock_wait_timeout = 18000

Innodb_log_file_sizeが2回あることに注意してください。よく見る...

innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G <----
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M <----
innodb_lock_wait_timeout = 18000

Innodb_log_file_sizeの最後の設定が優先されます。 MySQLは、ログファイルが5Mで起動する予定です。 mysqldを起動しようとしたとき、ib_logfile0およびib_logfile1は1Gでした。サイズの競合が発生し、抵抗が最も少ない経路が取られました。これはInnoDBを無効にすることでした。そのため、InnoDBはshow engines;にありませんでした。謎が解けた!!!

UPDATE 2011-10-17 11:07 EDT

Innodb_log_file_sizeが、当時1Gであったログファイル（ib_logfile0およびib_logfile1）よりも小さかったため、エラーメッセージは不正でした。興味深いのはこれです。ファイルが5Mであると予想され、ファイルが大きいため、破損が報告されました。状況が逆になり、innodbログファイルがmy.cnfで宣言されたサイズよりも小さい場合は、エラーログで次のようになります。

110216 9:48:41 InnoDB: Initializing buffer pool, size = 128.0M
110216 9:48:41 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 33554432 bytes!
110216 9:48:41 [ERROR] Plugin 'InnoDB' init function returned error.
110216 9:48:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

この例では、ログファイルはすでに5Mとして存在し、innodb_log_file_sizeの設定はより大きくなりました（この場合は32M）。

この特定の質問については、一貫性のないエラーメッセージプロトコルがMySQLのせいです（ええOracle（まだOracleは言っていません））。

6
RolandoMySQLDBA

エラーログは、データが破損していることを示しています。その場合、InnoDBはSHOW ENGINESで利用できなくなります。次の手順を実行して、 強制回復 を試すことができます。

  • s2でmysqlをシャットダウンする
  • my.cnfファイルにinnodb_force_recovery=1を追加します
  • mysqlを起動し、データがリストされているかどうかを確認します。

うまくいけば、それはそこにあり、あなたはあなたのデータを再ダンプしてS2に再ロードすることができます。

4
Derek Downey

私の場合、innodb_force_recovery=1を使用してもうまくいきませんでした。次に、接続を受け入れず、-1を使用した強制終了が機能しないmysqlの2番目のインスタンスが実行されていることを発見したため、サーバーを再起動することにしました。

再起動後、start slaveを実行すると、すべてが正常に戻りました。

0
Brad Mace