第262回　MySQLのInnoDBにおけるCheckpointの役割とパフォーマンス最適化を理解する

MySQLのストーレージエンジンであるInnoDBは、高い耐障害性とパフォーマンスを両立するために、バッファプールとredo logを用いた遅延書き込みアーキテクチャを採用しています。その中心にある仕組みが「Checkpoint」です。

CheckpointはクラッシュリカバリやI/O制御だけでなく、通常時のスループットやレイテンシにも大きな影響を与えます。本ドキュメントでは、Checkpointの役割、バッファプールとの関係、Sharp / Fuzzy Checkpoint、そして実運用におけるパフォーマンス観点について解説します。

Checkpointの概要

バッファプールにキャッシュされたページに変更が行われると、その変更は即座にデータファイルへ反映されるのではなく、後続処理としてディスクへ書き戻されます。この書き戻し処理は「フラッシュ」と呼ばれます。

InnoDBにおけるデータ更新の流れは、以下の通りです。

更新対象ページをバッファプール上で変更する
変更内容をredo logに記録する
トランザクションをコミット可能にする
データファイルへの書き込みは後続処理として行う

このとき、redo logには「どの変更がどの順序で行われたか」がLSN（Log Sequence Number）付きで記録されます。Checkpointとは、「⁠このLSN以前の変更はすでにデータファイルに反映済みである」と保証する位置であり、クラッシュリカバリ時の起点となります。

Checkpointが進まない状態ではredo logの使用領域が拡大し、最終的にはログを再利用できなくなります。その結果、新たな更新を書き込めなくなり、書き込み処理が停止する可能性があります。このため、CheckpointはInnoDBが継続的に書き込み処理を行うための重要な仕組みとなっています。

バッファプールの構成とLRU管理

バッファプールの役割

バッファプールは、InnoDBが管理するメモリ領域であり、テーブルやインデックスのページは必ずバッファプールを経由してアクセスされます。

更新処理も同様に、必ずバッファプール上で行われ、ディスクへの書き込みは後続処理としてまとめて実行されます。バッファプールを利用することで、頻繁に使用されるデータをメモリから直接処理できるため、ディスクI/Oを削減し、処理性能を向上させることができます。

MySQLでは多くの場合、物理メモリの約60％〜75％程度がバッファプールに割り当てられます。

LRUアルゴリズムによるページ管理

バッファプール内のページは、使用頻度に基づいて管理されます。この管理にはLRU（Least Recently Used）アルゴリズムをベースとした方式が用いられており、最近使用されたページほど長く保持され、使用頻度の低いページは追い出されやすくなります。

ただし、InnoDBでは単純なLRUではなく、バッファプールの特性に合わせて拡張された方式が採用されています。具体的には、LRUリストは以下の2つの領域に分割されています。

Old pages：読み込まれた直後のページ
Young pages：繰り返しアクセスされるページ

ページは一度読み込まれるとOld pagesに配置され、一定時間経過後に再アクセスされることでYoung pagesへ昇格します。これにより、フルスキャンなどの一時的なアクセスによるバッファプールの汚染を防ぎ、頻繁に利用されるページを効率よく保持できるようになっています。

デフォルトではinnodb_old_blocks_pctパラメータにより、Old pagesの割合は約37％に設定されています。

Dirty PageとCheckpointの関係

Dirty Pageとは

Dirty Pageとは、バッファプール上で更新されたものの、まだデータファイルに書き戻されていないページを指します。Dirty Pageはredo logによって保護されているため、更新直後に即座にディスクへ書き込む必要はありません。

しかし、Dirty Pageが増えすぎると、以下の問題が発生します。

Checkpointが進まない
redo logの使用量が増加する
急激なフラッシュが必要になる

そのため、InnoDBではDirty Pageを適切に制御しながらCheckpointを前進させる必要があります。このために、バックグラウンドでDirty Pageをディスクへフラッシュする仕組みが備えられています。

Sharp Checkpoint

Sharp Checkpointは、大量のDirty Pageを短時間で一気にディスクへフラッシュし、Checkpointを急激に進める方式です。

Sharp Checkpointは大量の同期I/Oを伴うため、オンライン処理中に発生するとレイテンシのスパイクやスループットの低下を引き起こします。ユーザー視点では、「⁠突然DBが遅くなった」「⁠書き込みが詰まった」と感じられることが多く、通常運用では極力避けるべき挙動です。

Fuzzy Checkpoint

Fuzzy Checkpointは、通常時に用いられるCheckpoint方式であり、バックグラウンドで少しずつDirty Pageをフラッシュします。

Fuzzy Checkpointの目的は、redo logの消費とDirty Pageの蓄積をバランスよく抑制し、Sharp Checkpointを発生させないことです。InnoDBはこの仕組みにより、I/O負荷を分散させつつ、安定した書き込み処理を維持できるよう設計されています。

パフォーマンス観点での注意点

Sharp Checkpointの回避

Sharp Checkpointはパフォーマンスに大きな影響を与えるため、運用上は可能な限り回避することが望まれます。主な発生要因は以下の通りです。

redo logの空きが不足し、ログ再利用のために古い領域を解放する必要がある
Dirty Pageの蓄積が大きく、Fuzzy Checkpointの通常処理が追いつかない
サーバのシャットダウンや再起動により、全Dirty Pageをフラッシュする必要がある

また、Checkpoint周りのパフォーマンスを考える際には、以下の要素をセットで考慮する必要があります。

バッファプールサイズ：過度に大きいとDirty Pageが溜まりやすくなる
redo logサイズ：小さすぎるとSharp Checkpointが頻発する
I/Oキャパシティ設定：小さすぎるとDirty Pageのflushが追いつかない

特にinnodb_io_capacity（バックグラウンドタスクで使用可能なIOPS）やinnodb_io_capacity_max（バックグラウンドタスクで使用される最大IOPS）が低すぎる場合、Dirty Pageが溜まりやすくなり、結果としてSharp Checkpointを誘発します。一方で高すぎる設定は、常時I/Oを圧迫する原因となります。

Checkpointは単体でチューニングするものではなく、バッファプール、redo log、ストレージ性能を含めた総合的な設計の中で最適化すべき要素です。

まとめ

InnoDBのCheckpointは、単なるクラッシュリカバリのための仕組みではなく、通常時の性能と安定性を大きく左右する重要な内部動作です。

Checkpointはredo log再利用の前提条件
Sharp Checkpointは避けるべき最終手段
Fuzzy Checkpointを安定して回すことが性能維持の鍵

適切な設定と継続的な監視により、安定したパフォーマンスを維持することが求められます。

第262回MySQLのInnoDBにおけるCheckpointの役割とパフォーマンス最適化を理解する