データベースページの破損を調査するために、SELECT ... INTO OUTFILE
を使用して、データベースからテーブルをダンプできます。通常は、この方法で取得されたデータのほとんどが完全な状態にあります。重大な破損では、SELECT * FROM
ステートメントまたは tbl_name
InnoDB
のバックグラウンド操作がクラッシュまたは表明したり、場合によっては InnoDB
のロールフォワードリカバリがクラッシュしたりすることもあります。このような場合は、テーブルをダンプできるように、innodb_force_recovery
オプションを使用して、バックグラウンド操作が実行されないようにして InnoDB
ストレージエンジンを強制的に起動させることができます。たとえば、サーバーを再起動する前に、オプションファイルの [mysqld]
セクションに次の行を追加できます。
[mysqld]
innodb_force_recovery = 1
innodb_force_recovery
を 0 を超える値に設定するのは、緊急の状況で InnoDB
を起動し、テーブルをダンプできるようにする場合だけにしてください。それを行う前に、データベースの再作成が必要になった場合に備えて、データベースのバックアップコピーがあることを確認してください。4 以上の値を指定すると、データファイルが永続的に破損する場合があります。本番サーバーインスタンス上で 4 以上の innodb_force_recovery
設定を使用するのは、使用するデータベースの個別の物理コピーでその設定を正常にテストしたあとだけにしてください。InnoDB
のリカバリを強制的に実行する場合は、常に innodb_force_recovery=1
から始め、必要がある場合にのみこの値を 1 ずつ増やすようにしてください。
innodb_force_recovery
は、デフォルトでは 0 です (リカバリが強制的に実行されない通常の起動)。innodb_force_recovery
の許可される 0 以外の値は 1 から 6 までです。大きい方の値には、小さい方の値の機能が含まれています。たとえば、3 の値には、値 1 と 2 のすべての機能が含まれています。
3 以下の innodb_force_recovery
値を使用してテーブルをダンプできる場合は、破損した個々のページ上の一部のデータしか失われないため、比較的安全です。4 以上の値は、データファイルが永続的に破損する場合があるため、危険であるとみなされます。6 の値は、データベースページが廃止された状態のままになり、それによって B ツリーやその他のデータベース構造にさらに多くの破損が導入される可能性があるため、きわめて危険であるとみなされます。
安全策として、innodb_force_recovery
が 0 より大きい場合、InnoDB
は INSERT
、UPDATE
、または DELETE
操作を回避します。MySQL 5.6.15 の時点では、4 以上の innodb_force_recovery
設定は InnoDB
を読み取り専用モードにします。
-
1
(SRV_FORCE_IGNORE_CORRUPT
)破損したページを検出した場合でも、サーバーが動作できるようにします。
SELECT * FROM
での破損したインデックスレコードおよびページの飛び越しを試行します。これが、テーブルのダンプに役立ちます。tbl_name
-
2
(SRV_FORCE_NO_BACKGROUND
)マスタースレッドや、すべてのパージスレッドが実行されないようにします。パージ操作中にクラッシュが発生しそうになった場合は、このリカバリの値によって回避されます。
-
3
(SRV_FORCE_NO_TRX_UNDO
) -
4
(SRV_FORCE_NO_IBUF_MERGE
)挿入バッファーのマージ操作を回避します。その操作によってクラッシュが発生しそうになった場合は、それが回避されます。テーブル統計を計算しません。この値を指定すると、データファイルが永続的に破損する場合があります。この値を使用したあと、すべてのセカンダリインデックスを削除して再作成するように準備してください。MySQL 5.6.15 の時点では、
InnoDB
を読み取り専用に設定します。 -
5
(SRV_FORCE_NO_UNDO_LOG_SCAN
)データベースを起動するときに、Undo ログを参照しません。
InnoDB
は、未完了のトランザクションでさえコミット済みとして処理します。この値を指定すると、データファイルが永続的に破損する場合があります。MySQL 5.6.15 の時点では、InnoDB
を読み取り専用に設定します。 -
6
(SRV_FORCE_NO_LOG_REDO
)リカバリに関連した Redo ログのロールフォワードを実行しません。この値を指定すると、データファイルが永続的に破損する場合があります。データベースページを廃止された状態のままにし、それによって B ツリーやその他のデータベース構造にさらに多くの破損が発生する可能性があります。MySQL 5.6.15 の時点では、
InnoDB
を読み取り専用に設定します。
テーブルからの SELECT
を実行してテーブルをダンプしたり、3 以下の innodb_force_recovery
値を使用してテーブルの DROP
または CREATE
を実行したりすることができます。ロールバック時に特定のテーブルでクラッシュが発生することがわかっている場合は、そのテーブルを削除できます。失敗した大量のインポートまたは ALTER TABLE
によってロールバックの暴走が発生する場合は、mysqld プロセスを強制終了し、innodb_force_recovery
を 3
に設定してロールバックなしでデータベースを起動したあと、ロールバックの暴走の原因になっているテーブルの DROP
を実行することができます。
テーブルデータ内の破損のためにテーブルの内容全体をダンプできない場合は、ORDER BY
句を含むクエリーで、破損した部分のあとにあるテーブルの部分をダンプできる可能性があります。
primary_key
DESC
InnoDB
を起動するために innodb_force_recovery
を大きな値にする必要がある場合は、複雑なクエリー (WHERE
、ORDER BY
、またはその他の句を含むクエリー) を失敗させることがある破損したデータ構造が存在する可能性があります。この場合は、基本的な SELECT * FROM t
クエリーしか実行できない可能性があります。