Tech Learning Daily

テーブルを書き換えるたびにディスクへ書くと遅すぎる

PostgreSQL のテーブルやインデックスは、8KB 程度の固定長ブロックであるページの集まりとしてデータファイルに格納されている。UPDATE を実行すると、DB はまずメモリ上の共有バッファにあるページを書き換える。ディスク上のファイルはまだ古いままだ。

COMMIT のたびに書き換えたページを全部ディスクへ書けば安全ではある。しかし 1 つのトランザクションは、テーブルの行・複数のインデックス・別テーブルなど、ファイル上で離れた位置のページを触る。離れた位置への書き込みはランダム I/O になり、さらに OS のページキャッシュを越えて物理ディスクまで届いたことを確認する fsync（ファイルの変更を記憶装置に確実に書き出させるシステムコール）をファイルごとに待つ必要がある。小さなトランザクションが毎秒何百件も来る Web アプリでは、この方式はすぐに詰まる。

かといってメモリ上の変更だけで「成功」を返せば、電源断で注文は消える。速さと耐久性（コミットしたデータは失われないという性質。ACID の D）を両立させるために使われているのが、WAL という仕組みである。

先にログを書く — WAL のたった一つのルール

WAL（Write-Ahead Logging、先行書き込みログ）のルールは「データファイルの変更は、その変更を記述したログがディスクに確定した後でなければ書き出してはならない」という一点だけだ。ログは「どのページのどこを何に変えたか」という変更記録の列で、pg_wal ディレクトリに、通常 16MB ずつのセグメントファイルとして追記されていく。

このルールの効果は、COMMIT 時に fsync すべきものが WAL ファイルだけになることだ。WAL は末尾に追記するだけなので書き込みはシーケンシャルで、散らばったデータページを書き出すより大幅に安い。さらに同時に多数のトランザクションがコミットする状況では、1 回の WAL の fsync で複数のトランザクションをまとめて確定できる。これをグループコミットと呼ぶ。

UPDATE … ; COMMIT; の流れ

アプリ      PostgreSQL         ディスク
  │ UPDATE    │                   │
  │──────────▶│ 共有バッファの    │
  │           │ ページを書き換え  │
  │           │ WAL レコード生成  │
  │ COMMIT    │                   │
  │──────────▶│ WAL を追記+fsync  │
  │           │──────────────────▶│pg_wal
  │◀──────────│ 成功を返す        │
  │           │                   │
  │           │ (数分後)          │
  │           │ チェックポイント  │
  │           │ ダーティページ    │
  │           │──────────────────▶│table
  │           │ 書き出し          │

COMMIT の時点でデータファイルが古いままでも困らないのは、クラッシュ後の起動時に WAL を読み直し、データページに反映されていない変更をやり直せるからだ。これをロールフォワードリカバリ、または REDO と呼ぶ。冒頭の問いの答えはここにある。注文はテーブルからではなく、WAL から戻ってくる。

チェックポイント — WAL を無限に溜めないための区切り

WAL だけで復元できるなら、データファイルへの書き出しはいつまでも後回しにできそうに思える。しかし実際はそうはいかない。後回しにするほど、クラッシュ後に再生すべき WAL が長くなり、ディスク上に保持すべき WAL も増え続けるからだ。そこで PostgreSQL は定期的にチェックポイントを実行する。チェックポイントでは、書き換え済みでまだディスクに書かれていないダーティページをすべて書き出し、WAL に「ここまでは反映済み」という印を残す。クラッシュリカバリはこの印から REDO を始め、それより前の WAL セグメントは再利用・削除できるようになる。

チェックポイントの間隔は 2 つの設定で決まる。checkpoint_timeout（デフォルト 5 分）が経過するか、WAL の量が max_wal_size（デフォルト 1GB）を超えそうになるか、どちらか早いほうで始まる。

# postgresql.conf
checkpoint_timeout = 5min   # 時間による発火
max_wal_size = 1GB          # WAL 量による発火
checkpoint_completion_target = 0.9

間隔を短くすると、再生すべき WAL が減るのでクラッシュ後の復旧は速くなる。代わりにダーティページの書き出しが頻繁になり、I/O が増える。加えてデフォルトで有効な full_page_writes により、チェックポイント後に初めて変更されるページはページ全体が WAL に書かれる。これは OS クラッシュで書きかけのページ（新旧が混ざった壊れたページ）が残っても、行単位の変更記録だけでは直せないためだ。結果としてチェックポイントを増やすと WAL の量も増える。checkpoint_completion_target（デフォルト 0.9）は、書き出しを次のチェックポイントまでの時間の約 9 割に分散させ、I/O の山を作らないための設定である。

大量の COPY やバッチ更新で WAL が急増すると、max_wal_size による発火が続いてチェックポイントが詰まる。間隔が checkpoint_warning より短くなるとサーバーログに max_wal_size を増やすよう促すメッセージが出るので、時々なら気にせず、頻発するなら max_wal_size を上げるのが定石だ。

「COMMIT を待たない」設定と「fsync をやめる」設定は別物

synchronous_commit（デフォルト on）を off にすると、PostgreSQL は WAL のディスク確定を待たずに COMMIT の成功を返す。WAL はバックグラウンドの WAL writer が wal_writer_delay（デフォルト 200ms）ごとに書き出すので、成功を返してから本当に確定するまでに隙間ができる。WAL writer は忙しい時にページ単位でまとめて書くよう設計されているため、この隙間の最大は wal_writer_delay の 3 倍、デフォルトなら約 600ms になる。

この隙間でクラッシュすると、成功を返したトランザクションが消える。ただし失われるのは「最後に確定した WAL より後のコミット」だけで、DB はその地点までコミット順に再生されるため、整合性は壊れない。そのため、トランザクション単位で選んで使える。

BEGIN;
SET LOCAL synchronous_commit = off;
INSERT INTO page_views (path) VALUES ('/top');
COMMIT;

一方 fsync = off は、WAL を含むすべての書き込みでディスク確定を待たなくなるサーバー全体の設定だ。WAL ルールの前提である「ログが先にディスクにある」が崩れるため、OS クラッシュや電源断でデータベースが任意に壊れうる。名前が似ていても、失うものが「直近のコミット」なのか「DB 全体の整合性」なのかで、重みはまったく違う。なお synchronous_commit には remote_write や remote_apply といった値もあり、レプリカに WAL が届くまで待つかどうかも同じ設定で制御する。レプリケーションもまた、この WAL を送り届ける仕組みの上に作られている。