MySQL 8.0 リファレンスマニュアル


15.21.2 InnoDB のリカバリの強制的な実行

データベースページの破損を調査するために、SELECT ... INTO OUTFILE を使用して、データベースからテーブルをダンプできます。 通常は、この方法で取得されたデータのほとんどが完全な状態にあります。 重大な破損により、SELECT * FROM tbl_name ステートメントまたは InnoDB バックグラウンド操作が予期せず終了またはアサートされたり、InnoDB ロールフォワードリカバリがクラッシュする可能性があります。 このような場合は、テーブルをダンプできるように、innodb_force_recovery オプションを使用して、バックグラウンド操作が実行されないようにして InnoDB ストレージエンジンを強制的に起動させることができます。 たとえば、サーバーを再起動する前に、オプションファイルの [mysqld] セクションに次の行を追加できます。

[mysqld]
innodb_force_recovery = 1

オプションファイルの使用の詳細は、セクション4.2.2.2「オプションファイルの使用」 を参照してください。

警告

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-trees およびその他のデータベース構造が破損する可能性があるため、劇的とみなされます。

安全策として、innodb_force_recovery が 0 より大きい場合、InnoDBINSERTUPDATE、または DELETE 操作を回避します。 innodb_force_recovery 設定が 4 以上の場合、InnoDB は読取り専用モードになります。

  • 1 (SRV_FORCE_IGNORE_CORRUPT)

    破損したページを検出した場合でも、サーバーが動作できるようにします。 SELECT * FROM tbl_name での破損したインデックスレコードおよびページの飛び越しを試行します。これが、テーブルのダンプに役立ちます。

  • 2 (SRV_FORCE_NO_BACKGROUND)

    マスタースレッドや、すべてのパージスレッドが実行されないようにします。 purge 操作中に予期しない終了が発生した場合、このリカバリ値によってそれが防止されます。

  • 3 (SRV_FORCE_NO_TRX_UNDO)

    クラッシュリカバリのあとにトランザクションロールバックを実行しません。

  • 4 (SRV_FORCE_NO_IBUF_MERGE)

    挿入バッファーのマージ操作を回避します。 その操作によってクラッシュが発生しそうになった場合は、それが回避されます。 テーブル統計を計算しません。 この値を指定すると、データファイルが永続的に破損する場合があります。 この値を使用したあと、すべてのセカンダリインデックスを削除して再作成するように準備してください。 InnoDB を読取り専用に設定します。

  • 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

    データベースを起動するときに、Undo ログを参照しません。InnoDB は、未完了のトランザクションでさえコミット済みとして処理します。 この値を指定すると、データファイルが永続的に破損する場合があります。 InnoDB を読取り専用に設定します。

  • 6 (SRV_FORCE_NO_LOG_REDO)

    リカバリに関連した Redo ログのロールフォワードを実行しません。 この値を指定すると、データファイルが永続的に破損する場合があります。 データベースページを廃止された状態のままにし、それによって B ツリーやその他のデータベース構造にさらに多くの破損が発生する可能性があります。 InnoDB を読取り専用に設定します。

テーブルから SELECT を使用してダンプできます。 innodb_force_recovery 値が 3 以下の場合、DROP テーブルまたは CREATE テーブルを使用できます。 DROP TABLE は、3 より大きい innodb_force_recovery 値でもサポートされています。 innodb_force_recovery 値が 4 より大きい場合、DROP TABLE は許可されません。

特定のテーブルがロールバック時に予期しない終了を引き起こしていることがわかっている場合は、そのテーブルを削除できます。 失敗した大量のインポートまたは ALTER TABLE によってロールバックの暴走が発生する場合は、mysqld プロセスを強制終了し、innodb_force_recovery3 に設定してロールバックなしでデータベースを起動したあと、ロールバックの暴走の原因になっているテーブルの DROP を実行することができます。

テーブルデータ内の破損のためにテーブルの内容全体をダンプできない場合は、ORDER BY primary_key DESC 句を含むクエリーで、破損した部分のあとにあるテーブルの部分をダンプできる可能性があります。

InnoDB を起動するために innodb_force_recovery を大きな値にする必要がある場合は、複雑なクエリー (WHEREORDER BY、またはその他の句を含むクエリー) を失敗させることがある破損したデータ構造が存在する可能性があります。 この場合は、基本的な SELECT * FROM t クエリーしか実行できない可能性があります。


関連キーワード:  InnoDB, テーブル, 構成, 破損, recovery, 実行, インデックス, 圧縮, リカバリ, スペース