データベース

データベースのトランザクションログとリカバリプロセスをわかりやすく解説

データベーストランザクション ログはすべての変更を最初に記録し、データページへの安全な書き込みを制御する。 sql耐久性 は、クラッシュが起きても無傷のままである。これらのログが解析、REDO、UNDOによるクラッシュリカバリーをどのように可能にするか、WALがI/Oをどのように制御するか、ポイントインタイムリカバリーが実際にどのように確実に機能するかについて説明する。.

中心点

ACID セキュア：トランザクションはアトミックで、一貫性があり、隔離され、永続的であり続ける。.
ウォル 第一：データページの前にログを書き込み、安全な確認を提供する。.
やり直し／取り消しクラッシュの後、変更を確認し、不完全な変更をキャンセルする。.
チェックポイントリカバリーを短縮し、ログの成長を抑制する。.
バックアップポイント・イン・タイム・リカバリのためのフルバックアップ、差分バックアップ、コンバインログバックアップ。.

トランザクションとACIDの簡単な説明

A トランザクション は複数のデータベース操作を1つの論理ユニットにまとめる。4つのACIDプロパティがガードレールを提供する：原子性が中途半端な状態を防ぎ、一貫性がルールと制約を保持し、分離が同時プロセスを切り離し、耐久性が確認されたデータを保護する。私は、関連するログ・エントリーが永久に書き込まれた後にのみCOMMITが行われるようにする。 耐久性 保証される。逆に、ROLLBACKはトランザクションのすべてのステップを取り消し、一貫性のある状態を復元します。つまり、エラーや停電、再起動が発生した場合でも、データベースは確実に使用可能な状態を維持します。.

ライト・アヘッド・ロギング（WAL）理解可能

時点では ウォル-原則としては、まずトランザクションログに順次変更を書き込み、データページが続く前にログをデータキャリアにフラッシュしてCOMMITする。この手順により、ランダムな書き込みアクセスが減り、I/O効率が向上し、すべてのデータページが即座に永続化されることなく、安全な確認が可能になる。RAMでは、バッファ内のページを変更し、前後の値を持つログレコードを作成し、それらをトランザクションIDにリンクする。COMMITが意味するのは、ログ・エントリーは永続的で、データベースは後で非同期にデータ・ページを書き込むことができるということだ。これは、クラッシュ後にログ-何が本当に確認されたのかを理解するために。.

ログ構造：セグメント、切り捨て、チェックポイント

トランザクションログは多くの場合 セグメント, これは、書き込みプロセスが計算可能なままであるように、データベースがローリングベースで使用するものである。セグメントが一杯になったら、次のセグメントに切り替え、既にバックアップされた古い領域は切り捨てによって解放する。チェックポイントは、リカバリーのためにより新しいログ・エントリーを読む必要がある状態を示す。より詳細な情報については、私のチェックポイントに関する注意事項と、書き込み増幅に関連するレバーの明確な分類がある。チェックポイントの間隔、自動成長、ログの最大サイズを注意深く計画すれば、ボトルネックを回避し、ログの最大サイズを維持することができる。修復計画的である。

クラッシュの復旧は3段階

クラッシュ後、データベースは最後の チェックポイント そして、どのトランザクションがアクティブであったか、どのデータページが影響を受けたか、どのコミットが利用可能かを分析することから始める。やり直しフェーズでは、確認された変更がまだデータページに完全に実装されていない場合、システムはそれを更新する。その後、undoフェーズで不完全なトランザクションをリセットし、中途半端な変更が表示されないようにする。このプロセスは自動的に実行され、ログやステータスメッセージで進捗状況や遅延の可能性を確認できる。決定的な要因は残っている：信頼できるログ-エントリーは、何が有効で何が有効でないかをシステムが認識することはできなかった。.

MySQL/InnoDB: クラッシュリカバリーの実際

InnoDB を使用すると、MySQL は やり直し-確認された変更のためのログと、オープンされたトランザクションのキャンセルのための取り消しログです。電源障害後の再起動時に、InnoDB はこれらのファイルを使用して、どのトランザクションが正しく完了したかを認識します。その後、MySQLは確認されたエントリに対してREDOオペレーションを実行し、Undoで不完全なトランザクションを取り消す。私は、計画外の再起動中にサーバーのメッセージをチェックして、リカバリの期間と進捗状況を確認し、フルボリュームなどのボトルネックを認識します。ログファイル、バッファサイズ、フラッシュ戦略を適切に設定すれば、リカバリ時間を短縮できる。 リカバリー-回はっきりと。.

性能対耐久性：現実的な妥協点

何れかの 耐久性-COMMITはログを永続的に書き込む必要があるため、レイテンシが発生する。SSDやNVMeのような高速ストレージ、グループ化されたフラッシュ、賢明なバッチパターンによって、このレイテンシを減らすことができる。分散セットアップの場合、非同期レプリケーションはローカルの書き込み経路を緩和することができるが、完全な障害が発生した場合、潜在的なデータ損失の小さな窓をもたらす。より厳格なフラッシュ・ポリシーのような設定は、セキュリティを向上させるが、レスポンス・タイムを長くする。より緩いモードは、レイテンシを減少させるが、COMMITの直後にクラッシュした場合にデータを危険にさらす。次の表は、一般的な手法とその効果をコンパクトにまとめたものである。.

テクノロジー	目的	待ち時間への影響	ヒント
WAL-フラッシュをCOMMIT	確認された取引の保護	ストレージが遅いほど高い	高速ログデータキャリアが功を奏す
グループ化フラッシュ	少ないI/Oコール	バンドルにより低下	タイムアウト/バッチサイズによる微調整
NVMe-メモリ	待ち時間のピークを低減	大幅に低下	ログボリュームを分ける
非同期レプリケーション	ローカル・コミットの緩和	地元ではもっと低い	小さなRPOウィンドウに注目

本番負荷の下でこれらの効果を測定し、レイテンシーとスループットの目標値を設定し、データ損失の要件と比較します。そして、パフォーマンスとスループットが最適化されるように、フラッシュ間隔、ログバッファ、ストレージメディアを調整します。 セキュリティ フィットする。

バックアップ戦略とポイント・イン・タイム・リカバリ

トランザクションログは、その潜在能力を最大限に発揮する。 バックアップ-フルバックアップ、差分または増分バックアップ、ログバックアップのチェーン。緊急時には、最後のフルバックアップをリストアし、差分バックアップまたは増分バックアップをリストアし、ログバックアップを必要な時点まで適用します。これによって、間違った大量変更やDELETEをWHEREなしでロールバックすることができる。手順とツールに関する背景情報は、私の比較にまとめてある。バックアップとスナップショット一緒に。定期的にリストアのテストをしておけば、時間の節約にもなるし、最悪の事態に陥ったときにも身を守ることができる。 データ 永久的な損失から。.

モニタリングと典型的なログの問題

フルログ-ボリュームは書き込み操作を止めるので、サイズ、成長、I/O利用率を継続的に監視している。適切でないリカバリモデルはログを肥大化させたり、ポイントインタイムリカバリを妨げる可能性があるので、展開シナリオに応じてモードをチェックしている。クラッシュ後の開始時間を短く保つために、チェックポイントの頻度、自動成長ステップ、切り捨て時間を意識的に計画しています。また、トランザクションのブロック、長いフラッシュ時間、ストレージのボトルネックなどを示すデータベースのエラーコードも記録しています。一貫して適用されるモニタリングはリスクを低減し 空室状況 高い。

リカバリーテスト、RTO、RPO

のないバックアップ テスト そのため、私は定期的に別のシステムでバックアップをインポートし、その手順をチェックしている。各アプリケーションについて、私はリカバリ時間の目標、つまり最大許容ダウンタイムとリカバリポイントの目標、つまり最大許容データ損失を定義する。これらの目標によって、バックアップ間隔、ログバックアップ頻度、レプリケーション戦略をコントロールする。クリーンな緊急時計画では、責任者、ツール、パスワード、保管場所、正確なコマンドシーケンスを指定する。文書化された実践があればこそ、迅速な修復嫌な驚きもなく。

仮想化、クラウド、レプリケーション

VMでもクラウドでも、私は以下を組み合わせている。 スナップ写真 をログバックアップと併用することで、柔軟なリストアポイントを作成することができる。マルチノードのセットアップでは、トランザクションログをほぼリアルタイムで追跡するレプリカのストリームとして使用することが多い。私は、スプリットブレイン・シナリオを回避し、フェイルオーバーを明確に規制する一貫性モデルを検討します。一般的な戦略の分類については、以下を参照してほしい。レプリケーションとフェイルオーバー. .ログデータの転送経路を知りたい場合や レイテンシー ゾーン間では、高可用性のために根拠のある決定を下す。.

内部ログの詳細：LSN、PageLSN、全ページ画像

各REDO/UNDOメカニズムには、連続したログシーケンス番号（LSN）が続く。各変更をLSNにリンクし、影響を受けるデータページにPageLSNも書き込みます。リカバリーの際、PageLSNがログエントリーのLSNより小さければ、REDOを適用しなければならない。破れた書き込みプロセスを認識するために、チェックサムを使用し、エンジンによっては 全ページ画像 またはダブルライトバッファを使用する。LSNロジックが複数回の実行を防ぐため、同じ変更を再度適用しても害はない。.

物理ロギングと論理ロギング - 両方が必要な理由

私は、物理的ロギング（ページ固有の差分またはページ全体）と論理的ロギング（行またはステートメント固有の操作）を区別している。物理的なログはコンパクトで素早く再作成でき、論理的なログは持ち運びが可能で、レプリケーションや監査に適している。多層のログ（ストレージエンジンのREDOと個別のレプリケーションログなど）を持つシステムでは、私は一貫性に注意を払う。確認されたCOMMITは、REDOとレプリケーションの両方のストリームできれいに表示されなければならない。これによって、ローカルでロバストにリカバリすると同時に、追跡可能で決定論的なレプリカを運用することができる。.

日常生活における孤立、MVCC、アンドゥ

ログは選択した分離と密接に連携する。MVCCでは、書き手が新しいバージョンを作成する間、読み手には一貫性のあるスナップショットを見させます。アンドゥ・ログはどのトランザクションも見ることができなくなるまで古い状態を保持します。そのため、私は意図的にパージ／バキューム処理を計画しています：長時間実行される読み込みトランザクションは古いバージョンのリリースをブロックし、ログを肥大化させます。実際には、トランザクションの実行時間に制限を設け、定期的なスナップショットのバックアップが古いバージョンの保持に与える影響をチェックし、履歴を必要とする読み込み負荷をできるだけプライマリシステムから遠ざけるようにしている。.

コミットパス、グループコミット、ハードウェアの影響

COMMITの継続時間は、安定したストレージへのパスによって決まる。私は、共通のフラッシュを持つ複数のトランザクションを確認し、システムが安定しているかどうかをチェックするためにグループコミットを使用する。 fsync/fdatasync 正しく、書き込みバリアは解除されない。バッテリーがサポートするライトバックキャッシュを備えたコントローラーや、停電保護機能を備えたSSDは、リスクとレイテンシーを低減する。MySQLのような環境では、フラッシュ・パラメータを意識的に調整する。厳しいモードは耐久性を確保し、緩いモードは稀なクラッシュ・ケースに負荷をシフトさせる。決定的な要因は、文書化されたリスク評価と、それを実測値で裏付ける能力です。.

ログの保持、暗号化、コンプライアンス

トランザクション・ログには機密性の高い内容が含まれることがあります。私はそれらを暗号化し、仕様に従ってキーをローテーションし、ログのバックアップも確実に保護します。RPO、法的要件、保管予算から保管期間を導き出します。監査のために、アクセス、ローテーション、削除のプロセスを追跡可能な方法で記録しています。個人データがログに残る可能性がある場合は、より高いレベルでマスキングをチェックするか、生データを含まない論理ログに頼っています。こうして、リカバリ可能性とデータ保護およびコンプライアンスを両立させている。.

ポイント・イン・タイム・リカバリーのステップ・バイ・ステップ

実際には、ポイント・イン・タイム・リストアの場合は次のように進める：クライアントの書き込みを停止するか、ターゲットシステムを隔離し、フルバックアップをベースに選択し、それを別のインスタンスにリストアする。その後、差分／増分バックアップを適用し、ログバックアップをイベント発生直前までロールアップする。ターゲットポイントをタイムスタンプまたはLSN/SCNとして定義し、すべてのログセグメントがギャップなく利用可能かどうかをチェックします。インポート後、整合性と副作用（トリガーサム、セカンダリーインデックスなど）をチェックし、その後システムをカットする。目標時刻を明確に決定できるように、事前にタイムソース、タイムゾーン、クロックスキューを文書化しておく。.

よくあるエラーパターンと迅速な対処法

ログセグメントが欠落している場合、インポートは中断されます。この場合、以前のリストアまたは既存のレプリカステータスのみが役立ちます。Log-LSN is in the future „のようなメッセージは、データファイルとログ履歴の不一致を示し、多くの場合間違ったコピー順序が原因です。REDOの破損は、保守的なリカバリーモード、リードオンリーで開始し、すぐに新しいクリーンなバックアップを作成することを強いる。チェックポイントが “ビハインド „で実行されることがない場合、私はログサイズを拡大したり、ダーティページの割合を減らしたり、I/Oを分散させたりして、REDOが連続バーナーにならないようにする。ログパーティションが一杯の場合：スペースを確保し、アーカイブを再開し、慎重にサービスを再起動する。.

キャパシティプランニングとベンチマーク

私は、実際の変化率に従ってログの寸法を決める。そのために、日次および週次プロファイルを使用してログ書き込みパスのMB/sを測定し、ピーク（バッチ、ETL、月末締め）を考慮に入れて、少なくともこのピークの倍数をバッファとして保持します。RAM上のログバッファがボトルネックになってはならない。そうでなければ、頻繁なフラッシュによりレイテンシが増大する。チェックポイントについては、クラッシュリカバリにかかる最大時間を明確に定義し、そこからダーティページとログウィンドウの目標値を導き出す。合成ツールは傾向を示すが、検証はレプリケーション、暗号化、メモリー保護メカニズムを含む現実的な負荷の下で行われる。そのとき初めて、RTO/RPOがコミットレイテンシの測定値と一致する。.

簡単にまとめると

トランザクションログは保険変更を文書化し、コミットを保存し、クラッシュ後にシステムを一貫性のある状態にリストアする。WALは日常的な使用やピーク時の負荷に対して十分に高速なプロセスを実現し、チェックポイントとトランケーションは開始時間とログサイズを制御下に保つ。フルバックアップ、差分バックアップ、ログバックアップによって、私はポイントインタイムリカバリーを実現し、ピンポイントでエラーをロールバックすることができる。モニタリング、リカバリーテスト、明確なRTO/RPO、カスタマイズされたストレージ技術を組み合わせれば、不必要なレイテンシーなしに信頼性を達成できる。一日の終わりに重要なのは、ログを理解し、維持し、定期的に実践することです。 データベース 緊急時でも対処可能だ。.