MySQL REDO ログの概念とは何ですか

トランザクションのACID特性において、アトミック性(A)、一貫性(C)、耐久性(D)はアンドゥログ、リドゥログによって実現され、分離性(I)はロックMVCCによって実現されます

UNDO ログ: トランザクションはまだコミットされておらず、途中で実行が異常です。UNDO ログを使用してデータをトランザクション実行前の状態に復元し、トランザクション

redo のアトミック性を確保できます。 log: ディスク データの更新に時間がかかるため、トランザクションのコミットは成功しました。この時点で例外が発生した場合は、REDO ログを使用してこのトランザクションの SQL を再実行し、トランザクションの耐久性を確保できます ( トランザクションのコミットが成功すれば、どのような異常なイベントが発生しても、次回 MySQL サービスが正常に進行する限り、コミットのデータは復元される必要があります。)

1. REDO ログの概念

REDO ログ: これは物理ログと呼ばれ、データの最終状態を直接保存し、データの耐久性を確保するために使用されます。

論理ログは、UNDO ログとも呼ばれ、対応する SQL ステートメントの特定の内容を記録します。ここで挿入を実行すると、ロールバック時に削除が実行されます。今更新を実行すると、元の古い値が更新されます。

REDO ログは /var/lib/mysql に配置されます。デフォルトでは、

トランザクションの開始時に REDO ログの記録が開始されます

(トランザクション全体が完了するため、トランザクションのコミット時には記録されません)コミット時にREDOログを書き込む場合、この時に例外が発生するとREDOログが書き込まれていない状態となり、手遅れとなりトランザクションの耐久性が確保できなくなります。 ) トランザクションがコミットされたかどうかに関係なく、トランザクションは記録されます。例外が発生した場合 (データ永続化中の停電など)、InnoDB は REDO ログを使用して停電前の時点に復元し、整合性を確保します。データの

innodb_log_buffer_size のデフォルトは 16M で、これは REDO ログ バッファのサイズです。トランザクションが開始されると、REDO ログの書き込みが開始されます。トランザクションが比較的大きい場合は、過剰な費用を避けるために、トランザクション実行中にディスク IO が大量に発生する場合、ディスク IO を節約するために比較的大きな REDO ログ キャッシュを設定できます。ディスクへのフラッシュにはリフレッシュ時間があり、その時間に達するとディスク IO が消費されます。バッファが比較的大きい場合、リフレッシュ時間に達するまでの時間が遅くなり、効率が高くなります。

InnoDB は操作データを変更します。ディスク上のデータを直接変更するのではなく、実際にはバッファ プール内のデータのみを変更します。 InnoDB は、クラッシュ後のデータ回復のために、常に最初にバッファ プール内のデータ変更を REDO ログに記録します。まず REDO ログを記録し、次に機会を見つけて、バッファ プール内のダーティ データをディスクにゆっくりと更新します。

innodb_log_group_home_dir で指定されたディレクトリ内の 2 つのファイル: ib_logfile0、ib_logfile1、このファイルは REDO ログと呼ばれます

バッファ プール キャッシュ プール: インデックス キャッシュ、データ キャッシュを保存できます。などにより、読み取りと書き込みの高速化、データ ページの直接操作、REDO ログの変更の書き込み、完了した場合でも、バッファ プール内のダーティ ページをディスクに書き込むための専用スレッドが存在します

バッファ プールのデフォルトのサイズは 134M (MySQL 5.7) です。

#一般的な構造は図に示すとおりです。

# トランザクションの読み取りと変更はすべて、プール内のキャッシュ操作データを優先します。実際のプロジェクトでは、mysqld は別のマシンで実行され、CRUD

2 を高速化するために大量のメモリを InnoDB のバッファ プールに特別に割り当てることができます。キャッシュとディスク構造

トランザクションがコミットされると、関係図上の操作は InnoDB ログ バッファーの内容をディスクに書き込むことです。書き込みが成功すると、ディスク上の REDO ログにステータスが記録されます -そうでない場合はコミット 書き込みが成功または完了した場合、レコード ステータス - prepare

ログには、ディスクへの書き込みプロセス中に例外、停電、その他の問題が発生する可能性があり、その結果、やり直しが書き込まれます。ログが完了していません (これは、トランザクションが正常にコミットされていないことに相当します)。このとき、MySQL はステータスがコミットされていないため、次回回復するときにトランザクションの整合性を考慮する必要はありません。すべてが書き込まれた場合のみです。ディスクにREDOログが正常に書き込まれたことを意味し、ステータスはコミットになります。ステータスがコミットに変更された後は、トランザクションの ACID 特性を維持する必要があります。

バッファ ポーリング内のダーティ データ (データが変更されている) は、コミット時にのみディスクに書き込まれるというのは本当ですか?

コミットが開始されるまで待つ必要はありません。トランザクションによって変更されるデータの量は比較的大きく、キャッシュ容量は限られています。バッファ ポーリングによってキャッシュされたデータについては、適切なタイミングでディスクを更新するための専用のスレッドが存在します。停電が発生した場合、次回 MySQL を起動すると、REDO に従ってリフレッシュされ、ログに記録されたデータが復元されます。

undo ログ自体も redo ログに記録されます

UNDO ログはトランザクションのロールバックをサポートしていますが、即座に完了することはできません。ディスク上のデータは最終的に変更されます。ロールバック プロセス中の例外を防ぐために、UNDO ログはやり直しログ。最下層では、操作が REDO ログに正常に書き込まれた後、トランザクションが正常にコミットされた (コミット) か、正常にロールバックされた (ロールバック) かにかかわらず、トランザクションは成功したとみなされます。

実際のトランザクション コミットの成功とは何ですか?

すべてのデータをディスクにフラッシュする代わりに、トランザクションの完全な操作を記録する REDO ログがログ バッファからディスクに書き込まれ、その後、変更されたデータのステータスが書き込まれます。 is set to commit. トランザクションのコミットは成功しました。この時点ではデータはまだバッファ ポーリングにありますが、REDO ログが完全に保存されていれば、データを復元できます。バッファ ポーリングのデータをディスクに書き込む専用のスレッドが存在します。

トランザクションが実行される操作時は、必ず最初に REDO ログを書き込み、次にバッファ プールに書き込みます。トランザクションが正常にコミットされた場合は、REDO ログが完全に記録されていることを確認する必要があります。ディスク

テーブル データ、バッファ プールのダーティ データ ページへの変更については、REDO ログが完全に書き込まれている限り、トランザクションがディスクにフラッシュされるかどうかを心配する必要はありません。ディスクにある場合は、REDO ログを使用して、正常にコミットされたトランザクションのデータ ステータスをいつでも復元できます (データベースで最も重要なのは、データではなくログです。)

以上がMySQL REDO ログの概念とは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。