MySQL innodb例外の修復に関する経験の共有

テスト用の MySQL ライブラリのセット。以前使用されていたバージョンは、centos6 のデフォルト ソースの MySQL 5.1.71 でした。その後、このライブラリには重要なデータがなかったため、Percona サーバー 5.7 を試してみたくなりました。そのため、操作前にバックアップは実行されず、ソースを設定した後、直接インストールが実行されました。データファイルもデフォルトの場所に保存されます。インストールが完了したら、MySQL を直接起動すると、起動に失敗し、正常に起動できないことがわかります。

1. MySQLをロールバックして再インストールする

このデータを他の場所からインポートする際のトラブルを回避するには、まず現在のライブラリ (/var/lib/mysql/ の場所) のデータベース ファイルのバックアップを作成します。次に、Percona サーバー 5.7 パッケージをアンインストールし、古い 5.1.71 パッケージを再インストールして、mysql サービスを起動しましたが、「不明/サポートされていないテーブル タイプ: innodb」というメッセージが表示され、正常に起動できませんでした。

110509 12:04:27 InnoDB: バッファプールを初期化しています。サイズ = 384.0M
110509 12:04:27 InnoDB: バッファプールの初期化が完了しました
InnoDB: エラー: ログ ファイル ./ib_logfile0 のサイズが 0 5242880 バイトと異なります
InnoDB: .cnf ファイルで指定された 0 157286400 バイトを超えています。
110509 12:04:27 [エラー] プラグイン 'InnoDB' 初期化関数がエラーを返しました。
110509 12:04:27 [エラー] プラグイン「InnoDB」のストレージエンジンとしての登録に失敗しました。
110509 12:04:27 [エラー] 不明/サポートされていないテーブルタイプ: innodb
110509 12:04:27 [エラー] 中止しています
110509 12:04:27 [注記] /usr/sbin/mysqld: シャットダウンが完了しました

/var/lib/mysql/ ディレクトリを削除し、データベース サービスを再起動して初期化します。正常です。show engines コマンドで innodb エンジンがあることがわかります。データベースを再度停止し、以前にバックアップした /var/lib/mysql/ ディレクトリの内容を現在の場所の内容で上書きして、再起動します。起動できないことが判明し、エラー内容も以前と同じでした。

/var/lib/mysql ディレクトリの内容の構造は次のとおりです。

-rw-rw---- 1 mysql mysql 10485760 2月26日 18:10 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2月26日 18:10 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2月26日 17:20 ib_logfile1
drwx------ 2 mysql mysql 4096 2月26日 17:20 mysql
drwx------ 2 mysql mysql 4096 2月26日 17:24 wiki

wiki ディレクトリはテスト データ用のライブラリ、ibdata1 ファイルはデータ ファイル、ib で始まる 2 つのファイルはログ ファイル、mysql ディレクトリにはシステム ライブラリに関連するものが含まれています。再度初期化したデータを使用し、wiki ディレクトリと ibdata1 ファイルを /var/lib/mysql ディレクトリに上書きします。正常に起動し、ログインできるようになります。

2. innodbモジュールを再インストールする

ただし、mysqldump を使用してバックアップすると、「不明なテーブル エンジン "Innodb"」というメッセージが表示されます。ログイン後、現在のすべてのエンジン タイプを確認したところ、確かに innodb タイプがないことがわかりました。

alter コマンドを使用して、テーブルの 1 つのタイプを MyISAM に変更しましたが、それでもエラーが発生することがわかりました。

find を通じて、/usr/lib64/mysql/plugin/ ディレクトリに ha_innodb_plugin.so ファイルがあることがわかりました。 MySQL 5 以降のバージョンでは、オンライン プラグインのインストールがサポートされている印象を受けます。以下をチェックして確認してください。確かにサポートされています。

次のコマンドを使用してロードすると、失敗することがわかりました:

プラグイン innodb soname 'ha_innodb.so' をインストールします。

3. バックアップ

/etc/my.cnf に次の設定を追加します。

プラグインロード=innodb=ha_innodb_plugin.so
プラグインディレクトリ=/usr/lib64/mysql/plugin/
デフォルトのストレージエンジン=InnoDB

起動は依然として失敗していることが判明しました。 mysql-error.log を確認すると、次の内容が見つかりました。

InnoDB: ディスク上のデータベースページが破損しているか、失敗した
InnoDB: ページ 7 のファイル読み取り。
InnoDB: バックアップから回復する必要がある場合があります。
InnoDB: オペレーティングシステムが
InnoDB: システムが自身のファイル キャッシュを破損しました
InnoDB: コンピュータを再起動すると、
InnoDB: エラー。
InnoDB: 破損したページがインデックスページの場合
InnoDB: 破損を修復することもできます
InnoDB: ダンプ、削除、再インポート
InnoDB: 破損したテーブル。CHECKを使用できます
InnoDB: テーブルの破損をスキャンする TABLE。
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html も参照してください。

forcing-innodb-recovery の公式ページを開くと、innodb_force_recovery パラメータを指定することで強制的に起動とリカバリを行えることがわかります。 /etc/my.cnf に次の内容を追加します。

innodb_force_recovery=6

再起動は成功しました。 mysqldump によるバックアップには問題はなく、バックアップ データを他のホストにインポートすることも正常に動作し、テストできます。

これは簡単に実行できます。mysql を完全に削除し、Percona サーバー 5.7 を再インストールします。インストール後、データベースを作成し、データを復元し、プログラムを再接続すると、すべて正常になります。

要約:

MySQL innodb データファイルの特性上、問題が発生してシステムを正常に起動できない場合は、まず ./ib_logfile0 と ./ib_logfile1 の 2 つのログファイルを移動してから再起動することができます。これが失敗した場合は、innodb_force_recovery パラメータを使用して強制的に回復することができます。また、ログも非常に再開可能です。疑問がある場合は、まずログを読んでください。