二重書き込みバッファとトーンページ問題

torn page はなぜ起きるのか

DBMS が読み書きする最小単位は ページで、InnoDB は既定 16KB、PostgreSQL は 8KB です。一方、ストレージがアトミックに（不可分に）書ける単位は伝統的な HDD で 512B、いまどきの SSD でも物理セクタ 4KB 程度にすぎません。つまり 1 ページの書き戻しは、内部的には複数セクタへの書き込みに分解されます。

ここに電源断が刺さると問題が起きます。ページの前半セクタは新しい内容、後半セクタは古い内容、という新旧が混ざった状態でディスクに残ることがあるのです。これが torn page（破れたページ、部分書き込み） です。

なぜ WAL だけでは防げないのか

「WAL（先行書き込みログ） があるなら、クラッシュ後に redo すれば直るのでは」と思うかもしれません。しかし WAL の redo は多くの場合物理論理（physiological）ログ、すなわち「このページのこのオフセットをこう書き換える」という差分を記録します。差分 redo が成立する前提は、再生の起点となるページが矛盾のない既知の状態であることです。

torn page はこの前提を破壊します。ページの一部が新・一部が旧という中途半端な状態に、さらに差分を当てても正しいページには戻りません。ページヘッダの pageLSN（最後に適用された WAL の LSN）すら、torn によって信用できなくなります。

正常: [旧ページ] --(redo差分を適用)--> [新ページ]   ← 起点が既知なので正しく直る
torn: [前半=新 / 後半=旧] --(redo差分)--> [?壊れたページ]  ← 起点が不定なので直らない

要するに redo は「ページ全体が壊れていないこと」を暗黙に仮定しており、torn page 対策はその仮定を物理層で保証するための別レイヤーです。解決の方針は一つ、「ページ全体を、torn の影響を受けない形でどこかにもう一部持っておく」ことです。

InnoDB: doublewrite buffer

InnoDB の答えが doublewrite buffer（二重書き込みバッファ） です。汚れたページをデータファイルの本来位置へ書き戻す前に、まずディスク上の連続した専用領域（doublewrite 領域）へそのページ群をまとめて書き、fsync します。そのうえで初めて、各ページを本来のランダムな位置へ書き、再度 fsync します。

書き込みは必ず「doublewrite 領域 → 本来位置」の順なので、クラッシュ時に壊れうるのはどちらか一方だけです。リカバリ時は各ページのチェックサムを検証し、本来位置のページが torn（チェックサム不一致）なら、doublewrite 領域にある無事なコピーで上書きします。

ポイントは、doublewrite 領域は連続領域へのシーケンシャル書き込みなので、ランダムな本来位置への書き込みに比べてコストが相対的に小さいことです。それでも全ページを 2 回書く以上、書き込み I/O 量はおおむね倍増します。

PostgreSQL: full-page write

PostgreSQL は別アプローチの full-page write（FPW、全ページ書き込み） を採ります。チェックポイント直後にそのページが最初に変更されるとき、通常の差分 WAL レコードの代わりに、変更後のページイメージ全体を WAL に書き込みます（同一チェックポイント区間で 2 回目以降の変更は通常の差分でよい）。

狙いは redo の起点を WAL 内に確保することです。クラッシュリカバリの redo 中に torn page を踏んでも、その区間の最初の FPW レコードがページ全体の正本を持っているため、ディスク上の torn なページをまるごと上書きして整合状態に戻し、そこから差分 redo を続けられます。「torn を検知して直す」のではなく、「torn かどうかに関わらず WAL の全ページで一旦塗り直す」のが本質です。

二つの設計の比較と性能コスト

両者は「ページ全体の正本を別の場所に持つ」点で同じですが、正本の置き場所が決定的に違います。

どちらも本質的に「同じデータを二度書く」ため、RUM 予想 でいう write amplification（書き込み増幅） を払って読み取り時の整合性（torn 耐性）を買っている、と整理できます。InnoDB はその重さをデータファイル側に、PostgreSQL は WAL 側に寄せています。

まとめ

torn page は「DB のページがストレージのアトミック書き込み単位より大きい」という構造から、正常なハードウェアでも電源断だけで生じます。WAL の差分 redo は無傷なページを起点に仮定するため、torn 対策は物理層の別レイヤーとして必要です。InnoDB は doublewrite buffer で本来位置の手前に二度書きして torn を修復し、PostgreSQL は full-page write でチェックポイント後の全ページを WAL に載せて塗り直します。いずれも書き込み増幅という対価を払って永続性（WAL が支える「D」）を本当に成立させる、最後の一歩です。ストレージのアトミック書き込みが保証できるなら、この対価の一部は安全に省けます。