停電で全部消えた (永続性)

事故 — 停電で 8 時間分の作業が消えた

終業間際、スタッフは Excel を保存し忘れたまま画面を開きっぱなしにして退勤した。 深夜 2 時、雷雨で停電。翌朝出勤して Excel を開くと、当日の受注データがまるごと消えていた。最終保存は朝 9 時。以降 17 時までの 8 時間分の作業が全滅。 自動回復ファイルにも 15 時までの断片しか残っていなかった。

原因 — Excel は明示保存後にしか確定しない

Excel の「変更」はメモリ上にしかない。Ctrl+S を押した瞬間、あるいは自動保存機能が発火した瞬間にしかディスクに書かれない。電源が落ちるとメモリの内容は消える。自動回復は数分単位の抜けを救うが確実ではない。

解決策 — WAL とコミット時の同期書き込み

RDB の COMMIT は「ログを永続ストレージに書き終わってから」アプリケーションに成功を返す。データ本体ファイルより先に、変更操作をログに記録する ことで、ログが確実にディスクに残っていれば後から状態を再現できる。これが WAL の原理。

COMMIT の裏では、OS のバッファではなく 物理ディスクへの書き込み完了まで DBMS が待つ (「同期書き込み」)。これで COMMIT 応答が返った時点で、 変更は電源喪失があっても失われない状態になっている。

クラッシュリカバリ — ロールフォワード + ロールバック

DBMS 起動時に クラッシュリカバリ フェーズを実行する:

1. ロールフォワード: REDO ログを再生し、コミット済みだがデータファイルに 反映が間に合っていなかった変更を再適用する
2. ロールバック: UNDO ログを使って、未コミットのまま中断した変更を取り消す

この 2 段階で「COMMIT 応答済みの変更は残り、未 COMMIT の変更は消える」が保証される。

境界事例

• 同期書き込みを無効化する高速化オプション: PostgreSQL のsynchronous_commit = off など。スループットは上がるが、電源喪失で数百 ms 分の コミットが失われる可能性がある。データが消えても再生できる用途 (キャッシュ、ログ収集) 以外では使わない
• グループコミット / ログのバッファリング: 複数トランザクションの WAL を まとめて 1 回で書き込む。スループットを稼ぎつつ永続性は保つ最適化
• レプリケーションと永続性: 同期レプリケーションを組めば primary クラッシュ時も レプリカで復旧可能。非同期だとレプリカに届かなかった数百 ms 分が失われる (RPO)
• 民生 SSD の電源保護: エンタープライズ SSD は電源保護コンデンサ内蔵、 民生 SSD は多くの場合内蔵していない。RDB サーバのストレージ選定で確認事項