MySQL トランザクションにおけるやり直しと元に戻すの分析 (画像とテキスト)

この記事の内容は、MySQL トランザクションの redo と undo の分析 (写真とテキスト) です。必要な方は参考にしていただければ幸いです。

トランザクションには、アトミック性、一貫性、分離性、耐久性という 4 つの特性があることは誰もが知っています。これがトランザクションの目的です。トランザクションの分離はロック機構によって実現され、トランザクションのアトミック性、一貫性、耐久性はREDOログとUNDOログによって保証されます。したがって、この記事では、トランザクションにおけるやり直しと取り消しに関するいくつかの問題について説明します。

• やり直しログと取り消しログとは何ですか?

• redo トランザクションの耐久性を確保するにはどうすればよいですか?

• UNDO ログは REDO ログの逆のプロセスですか?

redo ログ

Redo の種類

Redo ログ (REDO ログ) が使用されることを保証しますトランザクションの耐久性。これはトランザクション ACID の D です。実際には、次の 2 つのタイプに分類できます。

• #物理 REDO ログ

• 論理 REDO ログ

InnoDB ストレージ エンジンでは、

ほとんどの場合、Redo はデータ ページの物理的な変更を記録する物理ログです。論理 REDO ログは、ページの実際の変更を記録するのではなく、ページを変更する操作の種類を記録します。たとえば、新しいデータ ページを作成する場合、論理ログを記録する必要があります。論理 REDO ログに関しては、より低レベルのコンテンツが含まれます。ここで覚えておく必要があるのは、ほとんどの場合、ページ上の DML 変更操作は Redo を記録する必要があるということです。役割。 Redo の構成

Redo ログの主な機能はデータベースのクラッシュ回復です

Redo の構成

Redo ログは単純に次の 2 つの部分に分けることができます:

最初のファイルはメモリ内の揮発性の REDO ログ バッファです。
2 番目のファイルは永続的な REDO ログ ファイルです。
Redo を書き込むタイミングは?

上の図は、Redo の書き込みプロセスを簡単に示したものです。ここでさらに詳しく説明します。 REDO 書き込みのタイミング:

データ ページの変更が完了した後、ダーティ ページがディスクからフラッシュされる前に、REDO ログが書き込まれます。データが最初に変更され、ログが後で書き込まれることに注意してください
##REDO ログはデータ ページの前にディスクに書き戻されます

• #aggregation インデックス、セカンダリ インデックス、および元に戻すページへの変更はすべて、REDO ログに記録する必要があります。

• Redo の全体的なプロセス

以下では、次の図に示すように、マクロの観点から REDO ログ フロー プロセスを把握するために、更新トランザクションを例として取り上げます。 :

ステップ 1: まず、元のデータをディスクからメモリに読み取り、データのメモリ コピーを変更します。

• 2 番目のステップ: REDO ログを生成し、REDO ログ バッファに書き込み、データの変更された値を記録します。 3 番目のステップ: トランザクションがコミットされたら、REDO ログ・バッファーの内容を REDO ログ・ファイルにリフレッシュし、REDO ログ・ファイルへの追加書き込みを使用します。

• ステップ 4: 定期的にメモリ内の変更されたデータをディスクにコピーします

• REDO はトランザクションの耐久性をどのように確保しますか?
• InnoDB は、トランザクションのストレージ エンジンです。

  Force Log at Commit メカニズム

  を通じてトランザクションの耐久性を実現します。つまり、トランザクションがコミットされると、REDO ログ バッファーが最初に書き込まれます。 REDO ログ ファイルへの永続化は、トランザクションのコミット操作が完了するまで完了しません。このアプローチは、
Write-Ahead Log (ログ前永続化)

とも呼ばれ、データ ページを永続化する前に、メモリ内の対応するログ ページが永続化されます。

各ログが確実に REDO ログ ファイルに書き込まれるようにするため、デフォルトでは、REDO バッファが REDO ログ ファイルに書き込まれるたびに、InnoDB ストレージ エンジンは

fsync を呼び出す必要があります。 Operation ,REDO ログは O_DIRECT オプションなしで開かれるため、REDO ログは最初にファイル システム キャッシュに書き込まれます。 REDO ログがディスクに確実に書き込まれるようにするには、fsync 操作を実行する必要があります。 fsync はシステム コール操作です。そのため、ディスクのパフォーマンスはトランザクションの実行、つまりデータベースのパフォーマンスにも影響します。 (O_DIRECT オプションは Linux システムのオプションです。このオプションを使用すると、ファイルは直接 IO 操作され、ファイル システム キャッシュを経由せずにディスクに直接書き込まれます)

上記の Force Log at Commit メカニズム は、InnoDB ストレージ エンジンによって提供されるパラメータ
innodb_flush_log_at_trx_commit によって制御されます。このパラメータは、ディスクへの REDO ログのフラッシュ設定を制御できます。パラメータ値も次のように、ユーザーが非永続性を設定できるようにすることができます。

設定パラメータが 1 の場合 (デフォルトは 1)、トランザクションが次のように設定されている必要があることを意味します。 fsync コミット時に 1 回呼び出される操作。耐久性を確保する最も安全な構成です。

パラメータを 2 に設定すると、トランザクションのコミット時に write 操作のみが実行され、REDO ログ バッファのみがシステムのページ キャッシュに書き込まれることが保証されます。 、fsync 操作は実行されないため、MySQL データベースがダウンしてもトランザクションは失われませんが、

パラメータが に設定されている場合、オペレーティング システムがダウンする可能性があります。 0 の場合、トランザクションの送信時に REDO が書き込まれないことを意味します。ログ操作はマスター スレッドでのみ完了し、REDO ログの fsync 操作はマスター スレッドで 1 秒ごとに実行されるため、インスタンスがクラッシュします。最大 1 秒以内にトランザクションが失われます。 (マスター スレッドは、データの一貫性を確保するために、バッファ プール内のデータをディスクに非同期的に更新する役割を担います)

fsync および write操作 これは実際にはシステム コール関数であり、多くの永続化シナリオで使用されます。たとえば、Redis の AOF 永続化でも 2 つの関数が使用されます。 fsync 操作はデータをハードディスクに送信し、ハードディスクへの書き込みが完了して戻るまでブロックされます。 ## 操作にはパフォーマンスのボトルネックがあり、write 操作はシステムのページ キャッシュにデータを書き込んだ直後に戻り、システムのスケジューリング メカニズムに依存してキャッシュされたデータをディスクにフラッシュします。ユーザーバッファ—>ページキャッシュ—>ディスクです。

トランザクションの耐久性を確保するための、上記のコミット時にログを強制するメカニズムに加えて、REDO ログの実際の実装も依存します。ミニトランザクション用にオンにします。

Redo は InnoDB にどのように実装されますか?ミニトランザクションとの関係?

Redo の実装は、実際にはミニトランザクションと密接に関連しています。ミニトランザクションは、同時トランザクション操作下でデータ ページ内のデータを

確保するために使用されるメカニズムです。データベースが異常であるが、それがトランザクションの一部ではない場合。

ミニトランザクションがデータ ページ データの一貫性を確保するには、ミニトランザクションは次の 3 つのプロトコルに従う必要があります

:

FIX ルール

• #Write-Ahead Log

• Force-log-at-commit

• ## FIX ルール

データ ページを変更する場合は、ページの x-latch (排他ロック) を取得する必要があります。データ ページを取得する場合は、s-latch (読み取り) が必要です。ページのロックまたは共有ロック) または x-latch。ページを変更またはアクセスする操作が完了するまでページのロックを保持します。

先行書き込みログ

先行書き込みログについては、前の説明で説明しました。データ ページを永続化する前に、メモリ内の対応するログ ページをまず永続化する必要があります。各ページには、ログ シーケンス番号を表す LSN (ログ シーケンス番号) があります (LSN は 8 バイトを占め、単調増加します)。データ ページを永続デバイスに書き込む必要がある場合、必要なデータはページの LSN よりも少なくなります。ログは最初に永続化デバイスに書き込まれます。では、なぜ最初にログを書き込む必要があるのでしょうか。ログを書き込まずにデータをディスクに直接書き込むことは可能ですか?原理的には可能ですが、データ変更によりランダム IO が発生しますが、ログはシーケンシャル IO であるため、ディスクのパフォーマンスを最大限に発揮できます。活用されている。

Force-log-at-commit

これは、上記のトランザクションの耐久性を確保する方法の内容に相当します。トランザクション内で複数のページを変更できます。先行書き込みログは単一のデータ ページの一貫性を保証できますが、トランザクションのコミット時にすべてのページを生成する必要があるトランザクションの耐久性を保証することはできません。 mini - トランザクション ログをディスクにフラッシュする必要があります。ログのフラッシュが完了した後、バッファ プール内のページが永続ストレージ デバイスにフラッシュされる前にデータベースがクラッシュした場合、データベースの再起動時にデータの整合性が保たれる可能性があります。ログを通じて確認されます。

REDO ログの書き込みプロセス

上図は、各ミニの REDO ログの書き込みプロセスを示しています。 -transaction は、ミニトランザクションによって保証される更新ステートメントなどの各 DML 操作に対応します。データが変更された後、REDO1 が生成され、最初にミニトランザクションのプライベート バッファーに書き込まれ、更新されます。ステートメント 完了後、redo1 をプライベート バッファからパブリック ログ バッファにコピーします。外部トランザクション全体がコミットされると、REDO ログ バッファが REDO ログ ファイルにフラッシュされます。

undo ログ

undo ログの定義

undo ログは主に、データの論理的な変更を記録します。エラーが発生したときに前の操作をロールバックするには、以前の操作をすべて記録し、エラーが発生したときにロールバックする必要があります。

undo ログの役割

undo は 2 つの機能を持つ論理ログです:

トランザクションの場合ロールバック

• MVCC

ここでは MVCC (Multi-version Concurrency Control) については多くを述べませんが、トランザクション ロールバックの Undo ログに焦点を当てます。

undo ログは、ロールバック中にデータベースを論理的に元の状態に復元するだけです。たとえば、INSERT は DELETE に相当し、各 UPDATE は逆の UPDATE に相当します。変更前の行に戻ります。 UNDO ログは、トランザクションのアトミック性を確保するためにトランザクションのロールバック操作に使用されます。

#UNDO ログの書き込みタイミング

#DML 操作でクラスタード インデックスが変更される前に UNDO ログを記録します
セカンダリ インデックス レコードを変更しても、元に戻すログは記録されません。
元に戻すページを変更する場合も、REDO ログを記録する必要があることに注意してください。

アンドゥの保存場所

InnoDB ストレージ エンジンでは、アンドゥはロールバック セグメント (ロールバック) に保存されます。 セグメント)、各ロールバック セグメントは 1024 個のアンドゥ ログ セグメントを記録し、アンドゥは各アンドゥ ログ セグメントで実行されます。 5.6 より前では、ページを申請するには、ロールバック セグメントが共有テーブル スペースにありました。5.6.3 以降は、次の方法を使用できます。 innodb_undo_tablespace は、UNDO ストレージの場所を設定します。

アンドゥの種類

InnoDB ストレージ エンジンでは、アンドゥ ログは次のように分割されます:

アンドゥ ログの挿入
update undo log
insert undo log は、挿入操作中に生成された undo ログを指します。これは、挿入操作の記録が表示されるのは次のユーザーのみであるためです。トランザクション自体は他のトランザクションには見えません。したがって、UNDO ログはトランザクションの送信後に直接削除でき、パージ操作は必要ありません。

更新取り消しログには、削除および更新操作によって生成された取り消しログが記録されるため、トランザクションがコミットされたときに削除できないように、MVCC メカニズムを提供する必要がある場合があります。送信するときは、それを元に戻すログ リストに入れて、パージ スレッドが最終的な削除を実行するまで待ちます。

補足: パージ スレッドの 2 つの主な機能は、元に戻すページのクリーニングと、ページ内の Delete_Bit 識別子を持つデータ行のクリアです。 InnoDB では、トランザクションの Delete オペレーションは実際にはデータ行を削除しませんが、レコードを削除せずにレコードの Delete_Bit をマークする Delete Mark オペレーションです。これは一種の「偽の削除」であり、マークが付けられているだけであり、実際の削除作業はバックグラウンドのパージ スレッドによって完了する必要があります。

UNDO ログは REDO ログの逆のプロセスですか?

アンドゥログ やり直しですか? ログの逆の処理？実際、その答えは前の記事から導き出すことができます。Undo ログは論理ログであり、トランザクションをロールバックする場合、データベースを元の状態に論理的に復元するだけです。一方、REDO ログは論理的なログです。 ログは、データ ページの物理的な変更を記録する物理ログです。明らかに、UNDO ログは REDO ログの逆のプロセスではありません。

redo と undo の概要

次に、2 つのログ プロセスを理解しやすくするために、redo ログ undo ログのプロセスを簡略化して示します。実際、挿入/更新/削除操作では、やり直しと元に戻すでは異なる内容と量が記録されます。 InnoDB メモリでは、一般的なシーケンスは次のとおりです。

Write undo redo

• Write undo

• データの変更ページ

• やり直しの書き込み

• 概要

この記事では、やり直しの内容を分析します。およびアンドゥログは一部の情報書籍を参考にまとめており、明記されていない箇所があるかもしれません。何か間違っているところがあれば、ご指摘ください。

以上がMySQL トランザクションにおけるやり直しと元に戻すの分析 (画像とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。