# Write-Ahead Logging (WAL) ## 定義 書き込み前ロギング(Write-Ahead Logging、WAL)とは、データベースシステムにおいて、実際のデータ変更をデータページに反映する前に、変更内容をログに書き込む耐久性保証の基本原則である。WAL によって、クラッシュ発生後もコミット済みトランザクションの変更を再適用(Redo)し、未コミットのトランザクションの変更を取り消す(Undo)ことが可能になる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) WAL の実現方式には主に以下の種類がある: - **物理ロギング(Physical Logging)**: ディスクページのビフォア・アフタイメージを記録する。ページ ID・オフセット・変更前後のバイト列 - **生理ロギング(Physiological Logging)**: ページ内で物理的に変更を記録し、タプル間では論理的に記録する。ARIES が代表。ディスクページのスロットではなく論理的な操作(Insert/Update/Delete)の単位でログを書く - **論理ロギング(Logical Logging)**: 操作の効果を論理的に記録する。SQL 文や操作の意味でログを書く - **コマンドロギング(Command Logging)**: 論理ロギングの極端な形態。トランザクション名とパラメータのみを記録する ## 横断的知見 - **WAL 方式の選択がメインメモリ OLTP のスループット天井を決める**: Malviya+ 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])は、生理ロギング(ARIES 方式)がメインメモリ OLTP で TPC-C の最大スループットを 1.5× 低下させることを示した。これは Shore での先行研究([[@2008__SIGMOD__OLTP through the looking glass, and what we found there]])が 10–20% のオーバーヘッドを定量化したことの延長として位置づけられ、「スループットが上がるほどロギングの相対コストが増大する」という仮説を実験的に確認した。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **WAL オーバーヘッドは I/O と CPU の両方が原因**: 生理ロギングのオーバーヘッドはログデータのディスク書き込み量(TPC-C で 10× 多い)だけでなく、差分ログレコード構築の CPU コストにも起因する。ログレコードを人工的に 100 バイトに切り詰めた制御実験でも、スループット改善はわずか 1% にとどまった。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **「ログがデータベース」——WAL をストレージ層に押し出した場合、エンジン視点での Redo 責任の境界が消える**: Aurora([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])は WAL の Redo ログレコードのみをネットワーク越しに書き込み、ストレージ層のログアプライヤが非同期でデータページを実体化する。エンジンから見るとログレコードを書いた時点でコミットが成立し、物理ページは「ログ適用結果のキャッシュ」にすぎない。これは伝統的な WAL の「ログ → ページ」という二段階モデルを「ログ = データベース」という単段階に還元する設計であり、Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])が議論したメインメモリ OLTP での WAL コスト問題とは別のアプローチで I/O を削減する。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]], [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **SCL/PGCL/VCL/VDL は分散 WAL における LSN 一貫性ポイントの自然な拡張である**: 単一ノードの WAL では LSN と SCN が「ディスクにフラッシュした最高水位」を示す。Aurora 2018([[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]])はこれを分散化し、SCL（セグメント）→PGCL（Protection Group）→VCL（ボリューム全体）→VDL（ミニトランザクション境界）の 4 層階層で「分散 WAL のフラッシュ水位」を表現する。各水位は局所状態のみから計算でき、2PC のようなラウンドトリップ合意が不要。「ログだけが前進する」という不変条件がコンセンサス不要の基盤。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) - **VDL による MTR 原子性保証はレプリカの構造一貫性に直接つながる**: WAL の Mini-Transaction（MTR）は B-Tree スプリット等の複数ブロック変更をアトミックに記録する論理単位。Aurora ライターは VDL を「最後の MTR 完了 LSN」として定義し、このポイントをレプリカのレプリケーションストリームに通知する。レプリカは VDL 以上の MTR チャンクのみをキャッシュに適用するため、B-Tree の中途状態がレプリカに見えることがない。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) - **WAL が防ぐ「torn page」問題は、B-Tree の page 分割という複数page書き込みが本質的に非アトミックであることに由来し、教科書の一般原理と実装固有の生理ロギングは同じ危険源を異なる粒度で説明する**: DDIA 第4章は、B-Tree の page split のように複数 page を同時に上書きする操作が crash 時に危険であること(親を持たない orphan page や、ハードウェアが page 全体を原子的に書けない場合の torn page)を挙げ、WAL をこの危険に対する一般的な対策として説明する。既存知見([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])が定量化した生理ロギングのI/O・CPUオーバーヘッドは、この torn page 対策を実現する具体的な費用であり、DDIA の教科書的説明はその費用が生じる根本原因(page 上書きの非原子性)を示す。両者を合わせると、「なぜ WAL が必要か(page 上書きの非原子性)」と「WAL がどれだけ高くつくか(生理ロギングのI/O・CPUオーバーヘッド)」という因果関係の異なる2段が接続される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Making B-trees reliable", [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **fsync とバッファリングの関係は、教科書的な耐久性保証の最小条件として、Aurora のログのみ送信設計の前提になっている**: DDIA 第4章は、B-Tree 実装が性能向上のため変更 page をすぐにディスクへ書かずメモリ上でバッファリングし、WAL に書き込んで `fsync` でディスクへフラッシュした時点で耐久性が保証されると説明する。Aurora の「ログレコードのみをネットワーク越しに送りコミットとみなす」設計([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])は、この「WALのフラッシュ=耐久性」という単一ノードの最小条件を、ストレージ層への到達(クォーラム書き込み)に置き換えたものであり、DDIA が示す局所的な fsync 契約が分散システムでどう一般化されるかを示す具体例になっている。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Making B-trees reliable", [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **教科書(詳説 データベース)は WAL の実現方式を物理・生理・論理・コマンドロギングの4分類として体系化し、Malviya 2014 の定量比較はこの分類の生理ロギング対コマンドロギングという特定の2点間の性能差を測ったものだと位置づけられる**: 詳説 データベース5章は、物理ログ(ページ全体のビフォア・アフタイメージ)・論理ログ(操作の意味)・生理ログ(ページ内は物理・タプル間は論理、ARIESが代表)・コマンドロギング(論理ログの極端形態)という4方式の定義を与え、多くのシステムは「同時実行性のため論理ログでundo・リカバリ時間改善のため物理ログでredo」を組み合わせると説明する(MOHAN92 由来)。Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])が測定した「生理ロギングがTPC-Cスループットを1.5×低下させる」という結果は、この4分類のうち生理ロギングとコマンドロギングという両極端を比較した特殊ケースであり、教科書の分類軸に位置づけると、物理ログ単体・論理ログ単体という中間点の性能は依然未測定であることが分かる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.2.2, [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **steal/force ポリシーという教科書的な語彙が、Aurora の「ログだけを送りページはストレージ層が非同期生成する」設計の position を明確にする**: 詳説 データベース5章は steal(未コミットページのフラッシュを許容)/no-steal と force(コミット前に全変更ページをフラッシュ)/no-force の2軸4象限を定義し、ARIES は steal/no-force を採用すると説明する。Aurora([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])の「ログレコードのみを書きコミットとみなし、データページはストレージ層が非同期に実体化する」設計は、この分類でいえば steal(未コミット状態でもストレージ層はログを書き進める)かつ極端な no-force(コミット時点でページは一切フラッシュされていなくてよい)に相当し、単一ノードの steal/force ポリシー概念がクラウドネイティブなログオンリー送信アーキテクチャまで一貫して適用できる語彙であることを示す。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.2.3, [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **教科書自身が、B-TreeのWAL切り捨てとLSMツリーのWAL切り捨てを同じ設計原理の2つの現れとして明示的に対比する**: 詳説 データベース第7章は、memtableが完全にフラッシュされるまでその内容の唯一のディスク上バージョンが先行書き込みログに保持され、フラッシュ完了後にログのそのセクションを破棄できると説明したうえで、これをB-Treeと明示的に対比する——「B ツリーでは、永続性を保証するために、ログの切り捨てをページキャッシュからのダーティページのフラッシュと連携させる必要がある。LSM ツリーでも同様の必要性がある」。既存知見(本概念上記)がDDIA第4章から引いた「B-Treeのバッファリング→WAL書き込み→fsyncでの耐久性保証」という単一ノードの最小条件は、この対比によりLSMツリーのmemtable→WAL→フラッシュ完了後の切り捨てという別の構造にも一般化できることが、教科書自身の言葉で裏づけられる。フラッシュ前にログセグメントが破棄されクラッシュが起きるとそのセグメントのデータが復旧されないという失敗モードは、DDIAが挙げるB-Treeのtorn page問題と並ぶ、WAL切り捨てタイミングに起因する危険源のもう一例である。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]] §7.1.1.3, §7.5, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]] "Making B-trees reliable") ## 未解決の問い - NVRAM(不揮発性メモリ)が普及した場合、WAL のログをディスクでなく NVRAM に書き込むことで、I/O レイテンシ・CPU コストの両方が変化する。コマンドロギングと生理ロギングの優位性はどう変化するか？ - グループコミット最適化の最適パラメータ(バッチ間隔・バッチサイズ)はワークロードによって異なる。実行時に動的に最適化する手法は存在するか？ - Aurora の「ログのみ送信」設計はページ書き込みのネットワークコストを削減するが、ストレージ層でのログ適用 CPU コストはどの程度増加しているか？スケールアウトによる並列化がそれを相殺するかの実測は？ - 詳説 データベース5章が示す物理ログ単体(生理ロギングでもコマンドロギングでもない)を使うシステムの性能特性は、既存の定量比較(生理 対 コマンド)にどう位置づけられるか。中間点の実測データは存在するか。 ## 関連 - [[ARIES]] — WAL を実装した代表的な生理ロギング方式 - [[コマンドロギング]] — 論理 WAL の極端な形態 - [[クラッシュリカバリ]] — WAL が解決する問題 - [[チェックポイント]] — WAL と組み合わせてログ再適用範囲を制限する - [[メインメモリデータベース]] — WAL 設計選択が最も重要な環境 - [[OLTPシステムアーキテクチャ]] — WAL はログコンポーネントの一部 - [[コンピュートストレージ分離]] — ログ処理をストレージ層に移す Aurora 設計の文脈 - [[B-Tree]] — WAL は B-Tree の page 上書きを crash から保護する - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] — WAL の4分類(物理・生理・論理・コマンド)と steal/force ポリシーの教科書的な体系化 - [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]] — LSMツリーのmemtable durabilityにおけるWALの役割とB-Treeとのログ切り捨てタイミングの対比 - [[LSMツリー]] — memtableのフラッシュ完了までWALがデータレコードの唯一のディスク上バージョンを保持する ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](コマンドロギングと生理ロギングの詳細比較) - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]](「ログがデータベース」——Redo ログのみ送信・ストレージ層での非同期ページ生成) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 4 Storage and Retrieval]](§Making B-trees reliable — torn page・orphan page・fsyncによる耐久性の教科書的説明) - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]](§5.2 — WAL の4分類、steal/no-steal・force/no-force ポリシー、ARIES の位置づけ) - [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]](§7.1.1.3 memtableのWAL依存、§7.5 B-TreeとLSMツリーのWAL切り捨てタイミングの明示的対比)