MySQL の undo、redo、binlog の違いを簡単に分析します

序文

MySQL には、REDO ログ、UNDO ログ、バイナリ ログ、エラー ログ、スロー クエリ ログ、一般ログ、リレー ログの 6 種類のログ ファイルがあります。

その中で、REDO ログとロールバック ログはトランザクション操作と密接な関係があり、バイナリ ログもトランザクション操作と一定の関係があります。これら 3 つのログは、MySQL でのトランザクション操作を理解する上で非常に重要です。

【ログ取り消し】

トランザクションが開始する前に、現在のトランザクション バージョンの UNDO ログを生成します (ヒント: UNDO ログは、UNDO ログの信頼性を確保するために REDO ログも生成します)。

トランザクションがコミットされた後、UNDO ログはすぐに削除されず、リンク リストに格納されてクリーンアップされます。パージ スレッドは、UNDO セグメント内のテーブルで前のトランザクションより前のバージョン情報を他のトランザクションが使用しているかどうかを判断し、UNDO ログのログ領域をクリーンアップできるかどうかを決定します。

データベース トランザクションの 4 つの主要な特性の 1 つは、原子性です。具体的には、原子性とは、データベースに対する一連の操作が完全に成功するか、完全に失敗するかのいずれかであることを意味します。部分的な成功はあり得ません。

実際、基礎となるアトミック性は、UNDO ログを通じて実現されます。 UNDO ログは主にデータの論理的な変更を記録します。たとえば、INSERT ステートメントの場合、対応する DELETE UNDO ログがあります。各 UPDATE ステートメントには、対応する反対の UPDATE UNDO ログがあります。このようにして、エラーが発生した場合、トランザクション前のデータ状態をロールバックできます。たとえば、ユーザー テーブルの元のレコードは次のようになります。

sql update user set name = 'xiaohong' where id = 1;を実行すると、生成される undo ログはおそらくupdate user set name = 'xiaoming' where id = 1;なります。

同時に、UNDO ログは MVCC (マルチバージョン同時実行制御) の実装の鍵でもあります。

【REDOログ】

MySQL はどのようにしてトランザクションの永続性を確保するのでしょうか?最も簡単な方法は、トランザクションがコミットされるたびに、トランザクションに関係するすべての変更されたデータ ページをディスクに更新することです。ただし、そうすると、主に次の 2 つの点で重大なパフォーマンス上の問題が発生します。

• Innodb はページ単位でディスクとやり取りし、トランザクションではデータ ページ内の数バイトしか変更されない可能性があるため、この時点でデータ ページ全体をディスクにフラッシュするのはリソースの無駄になります。
• トランザクションには複数のデータ ページの変更が含まれる場合がありますが、これらのデータ ページは物理的に連続していないため、ランダム IO 書き込みを使用するとパフォーマンスが非常に低くなります。

そのため、MySQL は REDO ログ メカニズムを設計し、WAL (Write-Ahead Logging) テクノロジを通じてパフォーマンスを最適化しました。 WAL の中核は、最初にシーケンシャル IO でログ ディスクに書き込み、次にランダム IO でデータ ディスクに書き込むことで、ランダム ディスク書き込みの IO 消費を節約します。 MySQL は、DML ステートメントを実行するたびに、まずレコードを順番に REDO ログ バッファに追加し、メモリ内のデータを更新します。次に、アイドル スレッドがある場合、メモリが不足している場合、または REDO ログがいっぱいの場合、永続性を保つためにレコードをバッチでディスクに書き込みます。

【バイナリログ】

Binlog は MySQL の論理ログであり、サーバー層によって記録されます。任意のデータベース エンジンの書き込み操作 (クエリを除く) 情報を記録し、バイナリ形式でディスクに保存されます。

実際のアプリケーションでは、binlog は主にマスター スレーブ レプリケーションとデータ回復の 2 つのシナリオで使用されます。

• マスタースレーブレプリケーション: マスター側でバイナリログを開き、各スレーブ側にバイナリログを送信します。スレーブ側はバイナリログを再生して、マスタースレーブデータの一貫性を実現します。
• データ復旧: mysqlbinlog ツールを使用してデータを復旧します。

データ更新プロセス中に、システムに障害が発生して異常再起動した場合、トランザクションの永続性とアトミック性をどのように保証できますか?概要は次のとおりです。

1. この更新前のデータレコードのスナップショットサイトを記録する（つまり、UNDOログを書き込む）
2. この更新に必要なデータをメモリに読み込みます
3. メモリ内のデータを更新する（高効率）
4. REDOログを書き込み、REDOログのステータスを準備に設定します。
5. binlog の書き込み
6. REDOログのステータスをコミットに設定する

上記の簡略化された UNDO ログ、REDO ログ、および binlog 書き込みプロセスに基づいて、原子性、永続性、一貫性の信頼性保証を整理してみましょう。

A) ステップ 1/2/3 のいずれかで障害が発生した場合、リカバリ後に、REDO ログに未完了のレコードがないことがわかります。リカバリ後は、シーンを復元するために UNDO ログをロールバックするだけで済みます。

B) ステップ 4 または 5 のいずれかのステップで障害が発生し、障害回復後に REDO ログが準備状態にあることが判明した場合は、さらにそれが binlog に書き込まれているかどうかを判断します。

1. データがバイナリログに書き込まれている場合は、コミット状態が正常に達成されるまで（マスタースレーブ一貫性）、REDO ログの関連レコードを再実行します。
2. binlog が書き込まれていない場合は、undo ログをロールバックしてシーンを復元します (アトミック性)。
   

C) ステップ 6 で障害が発生した場合、リカバリ後に、REDO ログがコミットされた状態になっていることが確認され、プロセスが正常に完了したことが示されるため、何もする必要はありません。

要約する

これで、MySQL の undo、redo、binlog の違いに関するこの記事は終了です。MySQL の undo、redo、binlog の違いの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。