Mysql innodb例外修復プロセスの例

この記事は主に mysql innodb 例外修復の経験の共有を紹介します。必要な友人は参照してください。

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

1. 戻って mysql を再インストールします

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

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M
110509 12:04:27 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 157286400 bytes!
110509 12:04:27 [ERROR] Plugin 'InnoDB' init function returned error.
110509 12:04:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb
110509 12:04:27 [ERROR] Aborting
110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

/var/lib/mysql/ ディレクトリを削除し、データベース サービスを再起動し、初期化すると、ショー エンジンが 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 ファイルを見つけます。 mysql5 の新しいバージョンではオンライン プラグインのインストールがサポートされているという印象があります。実際にサポートされていることを確認するには、以下を確認してください:

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

install plugin innodb soname 'ha_innodb.so';

3. バックアップ

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

plugin-load=innodb=ha_innodb_plugin.so
plugin_dir=/usr/lib64/mysql/plugin/
default-storage-engine=InnoDB

それでもStartup failedであることが判明しました。 mysql-error.log をチェックして、次の内容を見つけます:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also 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 データファイルの特性により、問題が発生して正常に起動できない場合は、まず 2 つのログファイル ./ib_logfile0 と ./ib_logfile1 を移動してから起動できます。それでも失敗する場合は、 innodb_force_recovery パラメータを使用して強制リカバリを実行できます。さらに、ログは再起動可能でもあります。質問がある場合は、まずログを確認してください。

以上がMysql innodb例外修復プロセスの例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。