【DBスペシャリスト試験対策】Day 4：リカバリとログ管理まとめ
✅ 1. REDOログとUNDOログの違い
| 種類 | 内容 | 使用タイミング |
|---|---|---|
| REDOログ | 更新後の値を記録 | コミット済みを再実行（クラッシュ復旧時） |
| UNDOログ | 更新前の値を記録 | ロールバック時、未コミットの取消 |
- REDO → 「やり直し」
- UNDO → 「取り消し」
✅ 2. Write-Ahead Logging（WAL）
「データの更新よりも先にログを書け」
- REDO/UNDOログをディスクに先に書いてから、データ変更を行う
- 万が一クラッシュしても、ログからリカバリ可能
- WALは性能と安全性を両立させるための基本原則
✅ 3. チェックポイントとは？
「ここまでのデータは確実にディスクに書いた」印
- チェックポイントを設けることで、クラッシュ時のリカバリを短縮
- 実際の動作：
- バッファ内の変更済みページを書き出す
- WALログのLSNを更新
- 以降のログだけあれば復旧可能に！
✅ 4. クラッシュリカバリの流れ
- チェックポイント以降のログを読み込む
- REDO（再実行）：コミット済みのトランザクションを復元
- UNDO（取り消し）：未コミットの操作を取り消す
例：
[START T1] → [UPDATE A] → [COMMIT T1] → REDO対象
[START T2] → [UPDATE B] → （クラッシュ）→ UNDO対象
✅ 5. InnoDBとPostgreSQLの実装比較
【DBスペシャリスト試験対策】Day 4：リカバリとログ管理まとめ
✅ 1. REDOログとUNDOログの違い
| 種類 | 内容 | 使用タイミング |
|---|---|---|
| REDOログ | 更新後の値を記録 | コミット済みを再実行（クラッシュ復旧時） |
| UNDOログ | 更新前の値を記録 | ロールバック時、未コミットの取消 |
- REDO → 「やり直し」
- UNDO → 「取り消し」
✅ 2. Write-Ahead Logging（WAL）
「データの更新よりも先にログを書け」
- REDO/UNDOログをディスクに先に書いてから、データ変更を行う
- 万が一クラッシュしても、ログからリカバリ可能
- WALは性能と安全性を両立させるための基本原則
✅ 3. チェックポイントとは？
「ここまでのデータは確実にディスクに書いた」印
-
チェックポイントを設けることで、クラッシュ時のリカバリを短縮
-
実際の動作：
- バッファ内の変更済みページを書き出す
- WALログのLSNを更新
- 以降のログだけあれば復旧可能に！
✅ 4. クラッシュリカバリの流れ
- チェックポイント以降のログを読み込む
- REDO（再実行）：コミット済みのトランザクションを復元
- UNDO（取り消し）：未コミットの操作を取り消す
例：
[START T1] → [UPDATE A] → [COMMIT T1] → REDO対象
[START T2] → [UPDATE B] → （クラッシュ）→ UNDO対象
✅ 5. InnoDBとPostgreSQLの実装比較
| 項目 | InnoDB | PostgreSQL |
|---|---|---|
| REDOログ | あり | あり（WAL） |
| UNDOログ | あり | なし（Tupleで管理） |
| MVCC | Undoベース | Tupleバージョンベース（xmin/xmax） |
| リカバリ処理 | REDO＋UNDO | REDOのみ |
| データ掃除 | 自動またはPurge | VACUUM必要 |
✅ 6. ARIES（アリエス）方式
多くの商用DBで採用される高性能リカバリアルゴリズム
処理の3ステップ：
- Analysis（分析）：対象トランザクションを把握
- REDO：コミット済み処理の再実行
-
UNDO：未コミット処理の取り消し
→ CLR（Compensation Log Record） を記録して中断に備える
📚 まとめ
- WALは「書く順番」が命
- チェックポイントで回復速度UP
- REDO/UNDOはログの基本
- PostgreSQLとMySQLではMVCC実装が異なる
- ARIES方式は信頼性＆柔軟性◎
🔎 明日は「インデックスとパフォーマンスチューニング」などの物理設計に進む予定！
| 項目 | InnoDB | PostgreSQL |
|---|---|---|
| REDOログ | あり | あり（WAL） |
| UNDOログ | あり | なし（Tupleで管理） |
| MVCC | Undoベース | Tupleバージョンベース（xmin/xmax） |
| リカバリ処理 | REDO＋UNDO | REDOのみ |
| データ掃除 | 自動またはPurge | VACUUM必要 |
✅ 6. ARIES（アリエス）方式
多くの商用DBで採用される高性能リカバリアルゴリズム
処理の3ステップ：
- Analysis（分析）：対象トランザクションを把握
- REDO：コミット済み処理の再実行
-
UNDO：未コミット処理の取り消し
→ CLR（Compensation Log Record） を記録して中断に備える
📚 まとめ
- WALは「書く順番」が命
- チェックポイントで回復速度UP
- REDO/UNDOはログの基本
- PostgreSQLとMySQLではMVCC実装が異なる
- ARIES方式は信頼性＆柔軟性◎
🔎 明日は「インデックスとパフォーマンスチューニング」などの物理設計に進む予定！