14.16.1 InnoDB のリカバリプロセス

InnoDB のクラッシュリカバリは、次のいくつかのステップで構成されます。

• Redo ログの適用: Redo ログの適用は最初のステップであり、初期化中の、まだどの接続も受け入れていないときに実行されます。シャットダウンまたはクラッシュの時点で、バッファープールからテーブルスペース (ibdata* および *.ibd ファイル) にすべての変更がフラッシュされた場合は、Redo ログの適用をスキップできます。起動時に Redo ログファイルが見つからない場合、InnoDB は Redo ログの適用をスキップします。

  ある程度のデータ損失が許容可能な場合でも、リカバリプロセスを高速化するために Redo ログを削除することはお勧めできません。Redo ログの削除は、innodb_fast_shutdown が 0 または 1 に設定された状態でクリーンシャットダウンが実行されたあとのオプションにすぎないと考えてください。

• 未完了のトランザクションのロールバック: クラッシュまたは高速シャットダウンの時点でアクティブであったすべてのトランザクションが対象です。未完了のトランザクションをロールバックするためにかかる時間は、サーバーの負荷に応じて、そのトランザクションが中断される前にアクティブであった期間の 3 または 4 倍になる場合があります。

  ロールバックされている最中のトランザクションを取り消すことはできません。極端なケースとして、トランザクションのロールバックに膨大な時間がかかると予測される場合は、innodb_force_recovery の設定を 3 以上にして InnoDB を起動した方が速いことがあります。詳細は、セクション14.19.2「InnoDB のリカバリの強制的な実行」を参照してください。

• 挿入バッファーのマージ: インデックスページがバッファープールに読み取られたときに、挿入バッファー (システムテーブルスペースの一部) からセカンダリインデックスのリーフページに変更を適用します。

• パージ: どのアクティブなトランザクションにも表示されなくなった、削除のマークが付いたレコードを削除します。

Redo ログの適用に続く各ステップは (書き込みのロギングを除き) Redo ログには依存しないため、通常の処理では並列に実行されます。これらのうち、クラッシュリカバリに固有なのは未完了のトランザクションのロールバックだけです。挿入バッファーのマージとパージは、通常の処理中に実行されます。

Redo ログの適用のあと、InnoDB は、ダウンタイムを短縮するために接続をできるだけ早く受け入れようとします。クラッシュリカバリの一部として、InnoDB は、サーバーのクラッシュ時にコミットされていなかったか、または XA PREPARE 状態にあったすべてのトランザクションをロールバックします。このロールバックは、新しい接続からのトランザクションと並列に実行されているバックグラウンドスレッドによって実行されます。新しい接続では、ロールバック操作が完了するまで、リカバリされるトランザクションとのロック競合が発生する可能性があります。

ほとんどの状況では、負荷の高いアクティビティーの最中に MySQL サーバーが予期せず強制終了された場合でも、リカバリプロセスが自動的に実行されるため、DBA からのアクションは必要ありません。ハードウェア障害や重大なシステムエラーのために InnoDB データが破損した場合は、MySQL が起動を拒否する可能性があります。その場合は、このような問題をトラブルシューティングする手順について、セクション14.19.2「InnoDB のリカバリの強制的な実行」を参照してください。

バイナリログおよび InnoDB のクラッシュリカバリについては、セクション5.2.4「バイナリログ」を参照してください。