RDB Log
Overview
本番運用や障害復旧、レプリケーションなどに関わるなら「常識」レベル。 どのRDBでも似たような概念があります。
- PostgreSQL → WAL（Write-Ahead Logging）
- Oracle → Redo Log、Archive Log
- SQL Server → Transaction Log
- MySQL → Binlog（論理ログ） + Redo Log（InnoDBの物理ログ）
Binlog/Redo Log/WAL比較
| 用語 | 正体 | 対象DB | 主な用途 |
|---|---|---|---|
| Binlog | SQLレベルの変更記録 | MySQL | レプリケーション / PITR（復元） |
| Redo Log | 物理レベルの変更記録 | MySQL（InnoDB）, Oracle | クラッシュ復旧 |
| WAL | Redo Logと同義（PostgreSQL用語） | PostgreSQL | クラッシュ復旧、整合性維持 |
| 種類 | 属する層 | 主な目的 | 永続化のタイミング | 代表的なDB |
|---|---|---|---|---|
| Binlog | 論理ログ（SQL層） | レプリケーション、PITR（時間指定復元） | トランザクション確定後 | MySQL（InnoDB以外のエンジンも対象） |
| Redo Log | 物理ログ（ストレージエンジン層） | クラッシュリカバリ（障害復旧） | 書き込み直後（先行書き） | MySQL（InnoDB）、Oracle、PostgreSQL |
| WAL | 物理ログ（PostgreSQL専用用語） | Redo Logと同様：データ変更の信頼性確保 | 書き込み直後（先行書き） | PostgreSQL |
WAL（Write-Ahead Logging）
WALは、「先にログ（変更内容）を書き出してから実際のデータファイルを更新する」という信頼性重視の仕組み。
処理の流れ
- ユーザーが UPDATE を投げる
- 変更内容がまずWAL（ログ）としてディスクに書き込まれる
- その後、実際のテーブルファイルに反映される
メリット
- クラッシュ時でもログを使って「直前の状態まで正確に戻せる」
- 一貫性（ACID）を保ちやすい
ヒント
PostgreSQLではWALがRedo Log相当の役割を担っています。
Redo Log
InnoDBのRedo Logの仕組み（図つき）
+------------------+
| クエリ実行 |
+------------------+
|
v
+-----------------------+
| Redo Log に書き込む | ←★ 先にログを残す（WAL的な処理）
+-----------------------+
|
v
+-----------------------------+
| Buffer Pool（メモリ上のページ）|
+-----------------------------+
|
v（後で）
+---------------------+
| データファイルに反映 |
+---------------------+
補足ポイント
- Redo Logは2つの領域に分かれる
- ログバッファ（メモリ上、一時的）
- ログファイル（ib_logfile0 など、ディスク上）
- クラッシュ時はログファイルから復元され、データの一貫性が保たれる