サーバー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
テーブルはありますが!!
誰かが以前にそのような問題に直面したことがありますか?
どんなアイデアでも大歓迎です
ありがとう
Ibdata1ファイルを削除してはなりません。理由は次のとおりです。
ibdata1には、4つのタイプの情報が含まれています。
作成された各InnoDBテーブルには、いくつかの自動インクリメントメタデータ機能を介して各ibdファイルに数値IDが割り当てられています。その内部テーブルスペースID(ITSID)は.ibdファイルに埋め込まれています。その数は、維持されているITSIDのリストに照らしてチェックされます。
Ibdata1を再構築して正しいITSIDを設定することは可能ですが、それを行うには手間がかかります。私は個人的に一人で手順を行ったわけではありませんが、雇用主のWebホスティングでクライアントがこれを行うのを支援しました。私たちはこれを一緒に考え出しましたが、クライアントがibdata1をホースしたので、私は彼にほとんどの仕事をさせました(30のInnoDBテーブル)。
とにかく、ここではDBA StackExchangeで作成した過去の投稿です。根本的な原因がITSIDの混同であるという別の質問に答えました。
追跡を正しく行うには、 これはITSIDを参照して何をすべきか、およびibdata1をマッサージして.ibdファイル内に含まれるITSIDの存在を確認する方法を説明する記事です 。
ITSIDを使用してゲームをプレイする以外に、.ibdファイルを回復するための迅速で汚い方法はありません。
これがあなたの質問からのあなたの元の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;
にありませんでした。謎が解けた!!!
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は言っていません))。
エラーログは、データが破損していることを示しています。その場合、InnoDBはSHOW ENGINES
で利用できなくなります。次の手順を実行して、 強制回復 を試すことができます。
innodb_force_recovery=1
を追加しますうまくいけば、それはそこにあり、あなたはあなたのデータを再ダンプしてS2に再ロードすることができます。
私の場合、innodb_force_recovery=1
を使用してもうまくいきませんでした。次に、接続を受け入れず、-1
を使用した強制終了が機能しないmysqlの2番目のインスタンスが実行されていることを発見したため、サーバーを再起動することにしました。
再起動後、start slave
を実行すると、すべてが正常に戻りました。