CMU Database Systems をひたすら追っていく ~20 Logging Schemes~
この記事は「けんつの１人 DBMS アドベントカレンダー Advent Calendar 2019 - Adventar」 23 日目の記事です。
- はじめに
- Logging Schemes
- Failure Classification
- Buffer Pool Management Policies
- Write-Ahead Logging
- Checkpoint
- おわりに
はじめに
今日はログ周りの話。
WAL とか、ACID の原子性、耐久性、一貫性などを担保するための重要な要素。
Logging Schemes
リカバリアルゴリズムはデータベースに置いて一貫性、原子性、耐久性を確保する上で需要な要素となっている。
このリカバリアルゴリズムで行う大きく分けて２つにわかれる。
またここのでキーワードとして以下の２つがある。
Failure Classification
DBMS で起こる障害は大きくわけて 3 つに分類できる。
Transaction Failures
System Failure
Storage Media Failure:
- Non-Repairable Hardware Failure: ディスク障害、不揮発性ストレージの一部がクラッシュする。これから回復するにはアーカイブバージョンから復元するしかない。
Buffer Pool Management Policies
バッファプールを管理するポリシーの２つを紹介する。
例えば、No-Steal + Force で実装するなら。
変更がディスクに書き込まれなかった場合は、中止されたトランザクションによる変更を元に戻す必要はない。
また、コミット時に全ての変更がディスクに書き込まれることが保証されているため変更をやり直す必要はない。
ただし、トランザクションが変更する必要のある全てのデータがメモリに収まらない場合、トランザクションがコミットする前のダーティページをディスクに書き込まないため、そのトランザクションを実行できないという制限がある。
Write-Ahead Logging
ディスクページに変更が加えられる前にデータベースに加えられた全ての変更のログをログファイルに記録する手法。
殆どの DBMS で使用されているが、リカバリするためにはログを追う必要があるので処理に時間が掛かる。
ログはDBを復旧するための UNDO, REDO に必要な全ての情報を持っている。
Steal + No-Force システムを例に解説する。
Implementation
更新されたページの関連する全てのログレコードはページ自体がストレージに書きこまれるよりも前に永続化される。
- 全てのログレコードがストレージに書き込まれ、永続化されるまでトランザクションがコミットされたとはみなされない
- トランザクションが開始したら、各トランザクションのログに BEGIN レコードが書き込まれ開始点としてマークされる。
- トランザクションが終了したら、COMMIT レコードをログに書き込み、ログレコードがフラッシュされることを確認する。
- 各ログエントリには トランザクションID, オブジェクトID, 変更前の値(UNDOに使用)、変更後の値(REDOに使用) が格納される。
- トランザクションのコミット時にディスク全体のログ記録を行う必要がある。
Deferred Updates
Checkpoint
WAL の大きな問題としログファイルが肥大化するという問題がある。
クラッシュ時にこのログファイルが肥大化していると、ログを追ってリカバリする処理に時間がかかることがある。
そのため、チェックポイントを設け定期的にバッファの持つ情報をディスクにフラッシュする必要がある。
チェックポイントはどの程度設けるのが良いという基準はなく、チェックポイントが多すぎるとパフォーマンスが低下し、少なすぎるとその意味が薄れてしまう。
そのため、DBMS が担う役割や要求パフォーマンスに左右される。
おわりに
次はリカバリについて
