# クラッシュリカバリ ## 定義 クラッシュリカバリ(crash recovery)とは、データベースシステムがクラッシュ・電源断・ノード障害から回復し、コミット済みトランザクションの変更が確実に反映され、未コミットのトランザクションの変更が反映されない一貫性のある状態に復元するプロセスである。トランザクションの ACID 特性のうち「耐久性(Durability)」を、障害が発生した場合にも保証するための仕組みが復旧サブシステムである。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) **復旧の基本要件**: - クラッシュ前にコミットしたトランザクションの変更はすべてデータベースに反映される - クラッシュ時に実行中だった未コミットのトランザクションの変更は反映されない **復旧の起点**: - **WAL + チェックポイント方式**: ディスク上の最新チェックポイントから、WAL のログエントリを再適用(Redo)し、必要であれば未コミット変更を取り消す(Undo) - **コマンドロギング方式**: トランザクション整合性のあるスナップショット(チェックポイント)から、コマンドログに記録されたトランザクションを順番に再実行する ## 横断的知見 - **メインメモリ OLTP では復旧時間よりスループットが優先される**: Malviya+ 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])は、コマンドロギングの復旧時間が生理ロギングより 1.5×〜5× 遅いことを示したが、本番 OLTP はレプリケーションにより単一ノード障害をマスクできるため、復旧速度よりも実行時スループットの方が重要であると結論した。障害は週 1 回以下の頻度であるという議論も論文に示されている。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **インデックス再構築はスナップショット復元と並行化できる**: VoltDB ではディスクスナップショットにインデックスを含まないため、復旧時にインデックスを再構築する必要がある。コマンドロギング・生理ロギングともに、インデックス再構築はスナップショット復元と並行して実行できる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **生理ロギングの Redo フェーズは高度に並列化可能**: 異なるパーティションのログレコードは任意の順序で再適用できるため、コア数に比例してリニアスケールアップを達成する。コマンドロギングの再実行は直列(グローバル順序を守る必要がある)であり、並列化に制約がある。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **LLM 訓練チェックポイントとの類比**: データベースクラッシュリカバリは「スナップショット + ログ再適用」の構造を持ち、LLM 訓練の「チェックポイント + 勾配ステップの再実行」と同型の設計である。ただし意味論(commit/abort vs 最終損失収束)が異なる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **クラウド分散ストレージへの Redo 処理移譲により、リカバリは「連続的なフォアグラウンド処理」として実行される**: 伝統的な ARIES ベースのリカバリはデータベースがオフライン中にチェックポイントからログを順次再適用する（直列・同期）。Aurora([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])はストレージ層が常時バックグラウンドで Redo を適用するため、クラッシュ発生時点でほぼ全 Redo が完了済みである。起動後は各 PG の読み込みクォーラムで VDL を特定してログを切り捨てる truncation のみで済む。結果として 100,000 書き込み/秒のクラッシュでも 10 秒以内に復旧。チェックポイント間隔の短縮というトレードオフは不要になる。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **リカバリ速度 vs スループットのトレードオフはアーキテクチャ設計で変化する**: Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])ではコマンドロギングがリカバリ時間 1.5〜5 倍増と引き換えに実行時スループットを向上させた。Aurora はリカバリをフォアグラウンド処理に分散させることで、実行時スループット向上とリカバリ高速化の両方を同時に達成した。これはトレードオフの「軸」が設計選択によって変わることを示す。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]]) - **エポックベースフェンシングによりクラッシュリカバリ後の「ゾンビインスタンス」問題を解決できる**: 伝統的な分散システムでは、クラッシュしたノードが再起動中に古い接続でストレージにアクセスし続ける「ゾンビ問題」をリース有効期限で対処する。Aurora 2018([[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]])はリース待ちの代わりにボリュームエポックをインクリメントし、storage metadata service の書き込みクォーラムに記録する。古いエポックからのリクエストはストレージノードに即座に拒否される（「鍵を取り替える」）。これにより最大 30 秒かかりうるリース有効期限待ちが不要になり、フェイルオーバー時間が短縮される。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) - **Undo はリカバリ後にユーザー活動と並行して実行できる**: Aurora のクラッシュリカバリで行うのは「VCL の再計算 + ラグドエッジの truncation」のみ。アクティブトランザクションの Undo はデータベースを開いた後にバックグラウンドで実行する。これは伝統的な ARIES ベースリカバリ（Redo → Undo の直列処理）と異なり、ユーザー向けサービス再開までの時間をさらに短縮する。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) ## 未解決の問い - メインメモリデータベースにおいて、レプリケーション(高可用性)とコマンドロギング(耐久性)の組み合わせで、単一ノード障害と全ノード障害(電源断等)それぞれに対してどの程度のデータロスウィンドウが生じるか？ - コマンドロギングの復旧時間はトランザクション再実行速度に依存するが、復旧速度と実行時スループットのトレードオフはグループコミット間隔のチューニングでどの程度調整可能か？ - スナップショット頻度(180 秒固定)を動的に調整した場合、障害からの復旧時間分布はどう変化するか？ - Aurora の VDL 算定と truncation はリカバリ時に読み込みクォーラムへのネットワーク通信を必要とするが、AZ 障害直後のクォーラム再確立を含めると実際の 10 秒以内復旧はどのような条件で成立するか？ ## 関連 - [[Write-Ahead Logging (WAL)]] — 復旧の基本手法 - [[ARIES]] — 生理ロギングに基づく復旧アルゴリズム - [[コマンドロギング]] — 軽量な代替復旧手法 - [[チェックポイント]] — 復旧の出発点 - [[メインメモリデータベース]] — 復旧設計が特に重要な環境 - [[フォールトトレランス]] — より広い障害許容の文脈 - [[コンピュートストレージ分離]] — Redo をストレージ層に移す Aurora の設計文脈 - [[クォーラムベースレプリケーション]] — Aurora のリカバリが依拠するストレージ層クォーラム ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](コマンドロギングと生理ロギングの復旧時間比較) - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]](ストレージ層での継続的 Redo・VDL 算定・10 秒以内リカバリ)