[手順] MySQL データベースでの InnoDB 破損を修復するには

Plesk for Linux FR:PPM-2077 kb: how-to ABT: Group A

Applicable to:

Plesk for Linux

症状

以下のエラーが Plesk に表示される。

ERROR: PleskMainDBException
MySQL query failed: Incorrect information in file: './psa/misc.frm'

Plesk のアップグレードが以下のエラーで失敗する。
```
DATABASE ERROR!!!
Database psa found, but version undefined
```

MySQL サービスが起動しない。

/etc/init.d/mysqld start
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

テーブルが存在しないというエラーメッセージで mysqldump および mysqlcheck が失敗する（チェックには MySQL 管理者アカウントを使用します）。
```
mysqlcheck -uadmin -p****** db_example

db_example.BackupTasks
error    : Can't find file: 'BackupTasks.MYD' (errno: 2)
```

SELECT 文でテーブルに適切に問い合わせできない。

mysql> select * from db_example.misc;
ERROR 1033 (HY000): Incorrect information in file: './db_example/misc.frm'

InnoDB エンジンが修復をサポートしていないため、テーブルを修復できない。

mysql> repair table misc;
+-------------------------+--------+----------+---------------------------------------------------------+
| Table                   | Op     | Msg_type | Msg_text                                                |
+-------------------------+--------+----------+---------------------------------------------------------+
| psa.APSApplicationItems | repair | note     | The storage engine for the table doesn't support repair |
+-------------------------+--------+----------+---------------------------------------------------------+

MySQL ログファイルに以下の情報が見つかる。

150704 19:09:27 InnoDB: Waiting for the background threads to start
150704 19:09:28 InnoDB: Error: tablespace size stored in header is 3712 pages, but
150704 19:09:28 InnoDB: the sum of data file sizes is only 3072 pages
150704 19:09:28 InnoDB: Cannot start InnoDB. The tail of the system tablespace is
150704 19:09:28 InnoDB: missing. Have you edited innodb_data_file_path in my.cnf in an
150704 19:09:28 InnoDB: inappropriate way, removing ibdata files from there?
150704 19:09:28 InnoDB: You can set innodb_force_recovery=1 in my.cnf to force
150704 19:09:28 InnoDB: a startup if you are trying to recover a badly corrupt database.

原因

InnoDB が破損しています。

InnoDB の破損は、ほとんどの場合、ハードウェアに起因します。ページ書き込みの失敗は、電源喪失やメモリ不良に起因する可能性があります。また、NAS の使用時や、NAS への InnoDB データベースの割り当て時にも、問題が発生する場合があります。

解決策

注： MySQL サービスのコントロール、ログ、構成ファイルの場所は OS に応じて異なるため、本記事では一般的な例だけ示します。異なる OS 上の MySQL に関する追加情報は、以下の記事を参照してください。

[Linux] すべてのデータベース用のローカル MySQL サーバ

[Windows] 顧客のデータベース用のローカル MySQL サーバ

追加情報は、OS および MySQL のマニュアルを参照してください。

破損した MySQL データベースを修復するには、いくつかの方法があります。

I. InnoDB の修復

問題のある MySQL サービスを停止します。サービスのコントロールに関する上記の注意を参照してください。
MySQL データストレージファイルをすべてバックアップします。これらのファイルは、以下のディレクトリにあります。

/var/lib/mysql/ - all databases on Linux

%plesk_dir%\\Databases\\MySQL\\Data\\ - customers' databases on Windows

%plesk_dir%\\MySQL\\Data\\ - Plesk-related databases (psa, apsc, horde) on Windows.

例：
```
# mkdir /root/mysql_backup
# cp -a /var/lib/mysql/* /root/mysql_backup/
```
MySQL 構成ファイルで、 [mysqld] セクション（Plesk SQL Server on Windows の場合は [PleskSQLServer] ）の下で innodb_force_recovery の値を設定します。このオプションによって、MySQL サービスを起動し、すべてのデータベースのダンプを作成することができます。

例：
```
# vi /etc/my.cnf
[mysqld]
innodb_force_recovery = 1
```
警告： innodb_force_recovery は、緊急時にのみ 0 より大きい値に設定してください。これにより、InnoDB を起動し、テーブルをダンプすることが可能になります。値を 4 以上にすると、データファイルが恒久的に破損する可能性があります。そのため、この値は必要に応じて少しずつ上げていくようにしてください。詳しくは、 MySQL 公式マニュアルを参照してください。
MySQL サービスを起動します。
すべてのデータベースのダンプを試みます。
```
# mysqldump -uadmin -p`cat /etc/psa/.psa.shadow` -A | sed '1i\\SET FOREIGN_KEY_CHECKS = 0;' > /root/dumpall.sql
```
- ダンプが以下のようなエラーで失敗した場合：
```
Incorrect information in file: './psa/APSApplicationItems.frm' when using LOCK TABLES"`
```
  次に、 innodb_force_recovery の値を上げて、もう一度データベースのダンプを試みてください。
- データベースをダンプできない場合、以下の方法 II（テーブルコンテンツのコピー）または方法 III（バックアップからの復元）を試みてください。
mysql フォルダを除き、すべての MySQL データストレージファイルを削除します。例：
```
# rm -rf `ls -d /var/lib/mysql/* | grep -v "/var/lib/mysql/mysql"`
```
MySQL 構成ファイルから innodb_force_recovery オプションを削除します。
MySQL サービスを再起動します。
MySQL ログファイルでエラーをすべて確認します。
上の手順 #5 で作成したダンプからデータベースを復元します。例：
```
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` < /root/dumpall.sql
```

II. テーブル内容のコピー

方法 I の手順 1～4 を繰り返して、すべての MySQL データストレージファイルをバックアップし、InnoDB リカバリモードを有効化します。

テーブルのコピーの作成を試みます。

CREATE TABLE <new_table> LIKE <crashed_table>;
INSERT INTO <new_table> SELECT * FROM <crashed_table>;

コピーが正常に作成されたら、破損したテーブルを削除して、新しいテーブルを古いテーブルの名前に変更します。
```
DROP TABLE <crashed_table>;
RENAME TABLE <new_table> TO <crashed_table>;
```
注： MySQL バージョンによっては、 DROP および RENAME 操作を正常に実行するために、 innodb_force_recovery の値を低く設定したり、MySQL 構成ファイルから削除して MySQL サービスを再起動する必要があります。詳しくは、 MySQL 公式マニュアルを参照してください。

III. バックアップからの復元

上記の手順で修復できない場合、残された唯一の方法はバックアップからのデータベースの復元です。復元する前に、MySQL 構成ファイルから innodb_force_recovery オプションを忘れずに削除してください。

Plesk 関連のデータベース（psa、apsc、horde）を復元するには、 KB #213904125 を参照してください。例えば：

# ls -l /var/lib/psa/dumps
-rw------- 1 root   root   141960 Aug  8 01:03 mysql.daily.dump.0.gz
-rw------- 1 root   root   141925 Aug  7 01:03 mysql.daily.dump.1.gz

# zcat /var/lib/psa/dumps/mysql.daily.dump.0.gz | mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa

Plesk バックアップから顧客のデータベースを復元する場合、管理者ガイドの「バックアップアーカイブからデータを復元する」セクションを参照してください。

注：データベースの復元時にタイムアウトが発生する場合があります。この場合、MySQL 構成ファイルの wait_timeout の値を設定して、MySQL サービスを再起動してください。例：

# vi /etc/my.cnf
[mysqld]
wait_timeout = 1800

このセクションの記事

Applicable to:

症状

原因

解決策

I. InnoDB の修復

II. テーブル内容のコピー

III. バックアップからの復元

コメント

このセクションの記事

Applicable to:

症状

原因

解決策

I. InnoDB の修復

II. テーブル内容のコピー

III. バックアップからの復元

関連記事