Tech Learning Daily

DB はなぜデータファイルを直接書き換えないのか — WAL という前提

テーブルの行は最終的にディスク上のデータファイルに格納される。素朴に考えれば UPDATE のたびにそのファイルを直接書き換えればよさそうだが、実際の DB エンジンはそうしない。かわりに「このページのこの値をこう変える」という変更内容をWAL（Write-Ahead Log、先行書き込みログ）という追記専用のログファイルに先に書き、それをディスクへ fsync してからコミットを完了する。データファイル本体への反映は後回しにしてよい。

この順序には理由がある。データファイルはテーブルのあちこちに散らばったページをランダムな位置で書き換える必要があるが、WAL は末尾に追記していくだけなのでディスクへの書き込みが逐次アクセスになり高速だ。さらに、プロセスが途中でクラッシュしてもデータファイルへの反映が済んでいない変更は WAL に残っているので、再起動時に WAL を先頭から読み直して未反映の変更を再生（REDO）すれば、コミット済みのはずのデータが消えている事態を防げる。「コミット成功を返した以上そのデータは失われない」という約束は、WAL がディスクに確定していることによって成り立っている。

レプリケーションの正体 — WAL をコピーして再生するだけ

レプリカ（読み取り専用の複製サーバー）は、まっさらな DB にプライマリの WAL を延々と受け取って再生し続けているだけの存在だ。PostgreSQL のストリーミングレプリケーションでは、プライマリが生成した WAL をレプリカへ継続的に送信し、レプリカ側がそれを自分のデータファイルに適用していく。SQL 文をもう一度実行するのではなく、プライマリで確定した変更の記録をそのまま複製するので、プライマリとレプリカで実行計画が食い違って結果がズレる心配がない。

┌─ プライマリ ──────────────┐
│ UPDATE 実行               │
│  → WAL に追記 → fsync     │
│  → クライアントへ COMMIT 応答 │
└──────────┬────────────┘
           │ WAL をストリーミング送信
           ▼
┌─ レプリカ ────────────────┐
│ WAL 受信 → 順に再生（REDO） │
│  → ここでようやく反映      │
└────────────────────────┘

ここで見落としやすいのは、プライマリが「クライアントへ COMMIT 応答を返すタイミング」と「レプリカが WAL を受け取って再生し終えるタイミング」が別物だという点だ。両者の間に生じる時間差がレプリケーションラグで、PostgreSQL ではプライマリ側の pg_current_wal_lsn() とレプリカ側の pg_last_wal_replay_lsn() が指す WAL の位置（LSN）の差として観測できる。

なぜ既定で「非同期」なのか — 同期にするとどうなるか

PostgreSQL のストリーミングレプリケーションは既定で非同期だ。プライマリは WAL を自分のディスクに fsync した時点でクライアントにコミット完了を返し、レプリカへの転送や再生の完了は待たない。この設計だとプライマリが直後にクラッシュした場合、レプリカへ届く前の直近のコミットがレプリカ昇格後に失われる可能性がある一方で、レプリカの応答を待たない分コミットのレイテンシは低く保てる。

これを変えるのが synchronous_commit と synchronous_standby_names の組み合わせだ。synchronous_standby_names に同期対象のレプリカ名を指定し synchronous_commit = on（既定値）にすると、コミットは指定したレプリカが WAL をディスクへ書き込んだと確認するまで待つようになる。さらに remote_apply まで上げると、レプリカが WAL を受け取って再生を完了するまで待つため、直後に同じレプリカへ読みに行っても必ず最新のコミット結果が返る。ただしこの場合、同期対象のレプリカが落ちたり詰まったりすると、プライマリへの書き込みそのものがブロックされる。ラグをゼロに近づけることと、レプリカ障害時の可用性を両立させることはできない。

# postgresql.conf 側の抜粋（プライマリ）
synchronous_standby_names = 'replica1'
synchronous_commit = on        # replica1 の WAL fsync を待ってコミット完了
# remote_apply にすると replica1 での再生完了まで待つ（ラグはほぼゼロになる代わりに書き込みが遅くなる）

ラグを前提にした設計 — read-your-writes をどう守るか

非同期レプリケーションを使う以上、「自分が書いた直後の値を自分で読む」（read-your-writes）が読み取りレプリカ経由では保証されないという前提でアプリケーションを組む必要がある。よくある対処は、書き込み直後の確認読み取りだけプライマリへ向ける、あるいは書き込みから一定時間はキャッシュやセッション内の値をそのまま使い DB を再度読みに行かないという方法だ。レプリカのラグをメトリクスとして監視し、一定秒数を超えたレプリカを読み取り対象から一時的に外すロードバランサー設定を組むケースもある。

読み取りをレプリカに逃がす主な動機はプライマリの読み取り負荷の分散であって、ラグをゼロにすることではない。「レプリカを増やせば増やすほど整合性の保証が弱くなる」という感覚を持っておくと、read-your-writes が壊れるバグに遭遇したときにレプリケーション構成を疑う勘が働くようになる。