MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする-mysql チュートリアル-php.cn

この記事は、mysql ログに関する関連知識を提供します。注目する必要があるのは、バイナリログ (binlog) とトランザクションログ (REDO ログと UNDO ログを含む) です。皆様のお役に立てれば幸いです。

MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする

1、binlog

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

論理ログ: 単純に SQL ステートメントとして理解できます;
物理ログ: MySQL のデータはデータページに保存され、物理ログはデータページにデータを記録します。データページ。変更します。ここにコードスニペットを挿入します。

バイナリは追加によって書き込まれます。各バイナリファイルのサイズは、max_binlog_size パラメータを通じて設定できます。ファイルサイズが指定された値に達すると、ファイルサイズは次のようになります。ログを保存するための新しいファイルが生成されました。

binlog 使用シナリオ
プロジェクト実際のアプリケーションでは、binlog には 2 つの主な使用シナリオ、つまりマスター/スレーブレプリケーションとデータリカバリがあります。

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

MySQL マスター/スレーブ同期原理
MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする

マスターノードのバイナリダンプスレッド
ノードの接続マスターノードが使用される場合、マスターノードはログダンプスレッドを作成して、バイナリログの内容を送信します。ビンログの操作を読み取るとき、このスレッドはマスターノードのビンログをロックします。読み取りが完了すると、ロックはスレーブノードに送信される前でも解放されます。
スレーブノード I/Oスレッド
スレーブノードでスレーブ開始コマンドを実行した後、スレーブノードはマスターノードに接続するための I/O スレッドを作成し、マスターライブラリ内の更新されたバイナリログを要求します。 I/O スレッドは、マスターノードのバイナリログダンププロセスから更新を受信した後、それをローカルのリレーログに保存します。
スレーブノード SQL スレッド
SQL スレッドは、リレーログの内容を読み取る責任があります。そしてそれを特定の操作と実行に解析し、最終的にマスターとスレーブのデータの一貫性を確保します。
MySQL データベースのマスターとスレーブの同期原理

binlog content
として上で説明したように、binlog は、論理ログは単純に SQL ステートメントとして理解できますが、実際には、実行された SQL ステートメントの逆のロジックも含まれています。 delete は削除自体と逆挿入情報に対応し、update には対応する更新が実行される前後のデータ行に関する情報が含まれ、insert には独自の挿入情報と対応する削除情報が含まれます。

binlog 形式
binlog 形式には、ステートメント、行、混合の 3 つがあります。 MySQL 5.7.7 より前では、デフォルトでステートメントが使用され、MySQL 5.7.7 以降では、デフォルトで行が使用されていました。ログの形式は、my.ini 構成ファイルの binlog-format を通じて変更できます。
(1) ステートメント: SQL ステートメントに基づくステートメントベースのレプリケーション (SBR) データを変更する各 SQL ステートメントはバイナリログに記録されます。

利点: 特定の行の変更を具体的に記録する必要がないため、スペースが節約され、IO が削減され、パフォーマンスが向上します。
欠点: sysdate() やスリープなどの操作を実行する場合() 、マスターデータとスレーブデータの間で不整合が生じる可能性があります。

(2) 行: 行ベースレプリケーション (RBR)、SQL ステートメントのコンテキスト関連情報は記録されませんが、どの情報が記録されるか変更されるレコードの詳細。

利点: 各行レコードの変更の詳細が非常に詳細に記録されるため、データが正しくコピーできない状況は発生しません;
欠点: 各行は非常に詳細に記録される変更の詳細を記録します。これにより、大量のログコンテンツが生成されます。 update ステートメントがあり、多くのレコードが変更されたとすると、変更された各レコードは binlog に記録されます。特に、テーブルの変更操作では、テーブル構造の変更によりレコードの各行が変更され、その結果、ログの量が急激に増加します;

(3)mixed:上記、ステートメント、および行それぞれに長所と短所があるため、混合バージョンは 2 つを混合したものであるように見えます。通常はステートメント形式で保存しますが、ステートメントが解けない場合は行形式で保存します。
特に、上で述べたように、新しいバージョン (MySQL 5.7.7 以降) では、デフォルトで行形式が使用されます。ここでの行も、それに応じて最適化されています。テーブル変更操作が発生した場合、記録にはステートメント形式が使用されます。残りの操作では引き続き行形式が使用されます。

binlog フラッシュのタイミング

InnoDB ストレージエンジンの場合、binlog はトランザクションが送信されたときにのみ記録されます。この時点では、レコードはまだメモリ内にあります。、MySQL は sync_binlog を渡し、binlog のフラッシュのタイミングを制御します。値の範囲は 0 ～ N:

0: ディスクへの強制フラッシュはありません。いつディスクに書き込むかはシステムが決定します;
1: 送信ごとにバイナリログをディスクに書き込む必要があります;
N: Binlog は N トランザクションごとにディスクに書き込まれます;

上記からわかるように、sync_binlog の最も安全な設定は 1 であり、これは MySQL 5.7.7 以降のバージョンのデフォルト値でもあります。ただし、より大きな値を設定するとデータベースのパフォーマンスが向上するため、実際の状況では、値を適切に増やし、ある程度の一貫性を犠牲にしてパフォーマンスを向上させることもできます。

binlog の物理ファイルサイズ

my.ini 構成ファイルでは、binlog のサイズは max_binlog_size を通じて構成できます。ログのボリュームが binlog ファイルのサイズを超えると、システムは新しいファイルを再生成してファイルの保存を続行します。トランザクションが比較的大きい場合、またはログが増えて、トランザクションが占有する物理スペースが大きすぎる場合はどうすればよいでしょうか? MySQL には自動削除メカニズムが用意されており、これは my.ini 設定ファイルのexpire_logs_days パラメータを日単位で設定することで解決できます。このパラメータが 0 の場合は削除されないことを意味し、N の場合は N 日目後に自動的に削除されることを意味します。

2. redo ログ

redolog は、InnoDB エンジンの独自のログシステムです。これは主にトランザクションの耐久性とクラッシュセーフ機能を実現するために使用されます。 Redolog は物理ログであり、SQL ステートメントの実行後にデータページ上の特定の変更を記録します。
MySQL の実行中にデータがディスクからメモリにロードされることは誰もが知っています。 SQL文を実行してデータを変更した場合、実際には変更内容は一時的にメモリ上に保存されるだけで、このときに電源が切れるなどの事情が発生すると変更内容は失われます。したがって、データを変更した後、MySQL はこれらのメモリレコードをディスクにフラッシュする機会を探します。しかし、主に 2 つの側面でパフォーマンスの問題があります:

InnoDB はページのデータ単位でディスクと対話し、完全なデータページがフラッシュされた場合、トランザクションはページ上の数バイトのみを変更する可能性があります。ディスクに戻すと、リソースが無駄になります。

トランザクションには、複数のデータページが含まれる場合があります。これらのデータページは、論理的に連続しているだけで、物理的に連続していません。ランダム IO を使用します。パフォーマンスが低すぎます。

したがって、MySQL は、トランザクションによってデータページに加えられた特定の変更を記録し、その REDO ログをディスクにフラッシュするように REDO ログを設計しました。疑問に思われるかもしれませんが、もともと io を減らしたかったのですが、これでは別の io が追加されるのではないか? InnoDB の設計者は、設計の開始時にこれらを考慮しました。通常、REDOLOG ファイルは比較的小さく、ディスクにフラッシュバックするプロセスはシーケンシャル IO であるため、ランダム IO よりもパフォーマンスが優れています。

REDO ログの基本概念
REDOLOG は 2 つの部分で構成されます。1 つはメモリ内のログキャッシュ REDO ログバッファで、もう 1 つはメモリ内のログファイル REDO ログファイルです。ディスク。データレコードが変更されるたびに、これらの変更はまず REDO ログバッファに書き込まれ、その後、メモリ内の変更が REDO ログファイルにフラッシュされる適切な機会を待ちます。最初にログを書き込んでからディスクに書き込むこの技術が WAL (Write-Ahead Logging) 技術です。 REDO ログはデータページの前にディスクにフラッシュされることに注意してください。クラスタードインデックス、セカンダリインデックス、および UNDO ページへの変更はすべて REDO ログに記録する必要があります。

コンピュータオペレーティングシステムでは、ユーザー空間のバッファデータは通常、ディスクに直接書き込むことができず、オペレーティングシステムのカーネル空間バッファ (OS バッファ) を経由する必要があります。)。したがって、REDO ログバッファを REDO ログファイルに書き込むと、実際には最初に OS バッファに書き込まれ、次にシステムコール fsync() を通じて REDO ログファイルにフラッシュされます。プロセスは次のとおりです。
mysql サポート innodb_flush_log_at_trx_commit パラメータを使用して、REDO ログバッファを REDO ログファイルに書き込む 3 つのタイミングを設定できます。各パラメータ値の意味は次のとおりです: MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする

パラメータ値 0 (遅延書き込み) 1 (リアルタイム書き込み、リアルタイムブラッシング) 2 (リアルタイム書き込み、遅延ブラッシング)

MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする
redo ログの記録形式
REDO ログは固定サイズ、周期書き込み形式を採用しており、REDO ログがいっぱいになると再度最初から書き込まれます。なぜこのように設計されているのでしょうか?
REDO ログの主な目的は、データページのフラッシュの要件を軽減することです。 Redolog はデータページの変更を記録しますが、データページもディスクにフラッシュバックされると、これらの記録は役に立たなくなります。したがって、MySQL が以前の redolog の有効期限が切れたと判断すると、新しいデータが無効なデータを上書きします。では、対象となるべきかどうかはどのように判断すればよいのでしょうか？
MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする
上の図はREDOログファイルの模式図で、write posはREDOLOGが現在記録しているログシーケンス番号LSN(ログシーケンス番号)を表します。データページがディスクにフラッシュされると、REDO ログファイル内の LSN が更新され、この LSN より前のデータがディスクに書き込まれたことが示されます。この LSN がチェックポイントです。書き込み pos とチェックポイントの間の部分は、新しいレコードを記録するために使用される redolog の予備部分です。チェックポイントと書き込み pos の間の部分は、redolog が記録したデータページの変更された部分ですが、データページは変更されていません。この時点でディスクにフラッシュバックされました。書き込み pos がチェックポイントに追いつくと、まずチェックポイントを前方に押し出し、その位置を空けてから、新しいログを記録します。

innodb を起動すると、前回正常にシャットダウンされたか異常にシャットダウンされたかに関係なく、常に回復操作が実行されます。リカバリ中、最初にデータページ内の LSN がチェックされ、この LSN が REDO ログ内の LSN、つまり書き込み位置より小さい場合、データページ上の未完了の操作が REDO ログに記録されていることを意味します。そして、最も近いチェックポイントから開始され、データの同期が開始されます。

データページの LSN が redolog の LSN より大きい可能性はありますか?答えはもちろん可能です。これが発生すると、redolog 以降の部分はやり直しされません。これ自体、実行された内容をやり直す必要がないことを意味するためです。
REDO ログと binlog の違い

#意味
トランザクションがコミットされると、REDO ログバッファー内のログがOS バッファには書き込まれませんが、毎秒 OS バッファに書き込み、fsync() を呼び出して REDO ログファイルに書き込みます。つまり、0 に設定すると、データは (約) 毎秒ディスクに書き込まれ、システムがクラッシュすると 1 秒間のデータが失われます。
トランザクションが送信されるたびに、REDO ログバッファ内のログが OS に書き込まれます。バッファと fsync() が呼び出され、REDO ログファイルにフラッシュされます。この方法では、システムがクラッシュしてもデータは失われませんが、各送信がディスクに書き込まれるため、IO パフォーマンスは低下します。
各送信は OS バッファーにのみ書き込まれ、その後 fsync() が毎秒呼び出され、 OS バッファ内のデータログは REDO ログファイルに書き込まれます。

##REDO ログbinlogファイルサイズREDO ログのサイズは固定です。 Binlog は、構成パラメータ max_binlog_size を通じて各 binlog ファイルのサイズを設定できます。実装方法REDO ログは InnoDB エンジン層によって実装され、すべてのエンジンがこれを備えているわけではありません。 Binlog はサーバー層で実装されており、すべてのエンジンで binlog ログを使用できます記録方法REDO ログはループ書き込み方式で記録されます。最後まで書き込むと最初に戻ってループでログを書き込みます。 binlog は追加で記録されます。ファイルサイズが指定された値より大きい場合、以降のログは新しいファイルに記録されます適用可能なシナリオredo ログはクラッシュリカバリに適しています (クラッシュセーフ)binlog はマスター/スレーブレプリケーションとデータリカバリに適しています

これは、binlog と REDO ログの違いからわかります。binlog ログはアーカイブにのみ使用され、binlog のみに依存するとクラッシュセーフ機能がありません。ただし、REDO ログだけは機能しません。REDO ログは InnoDB に固有であり、ログ内のレコードはディスクに書き込まれた後に上書きされるからです。したがって、データベースをシャットダウンして再起動したときにデータが失われないように、binlog と REDO ログの両方を同時に記録する必要があります。
2 段階の送信
上記では redolog と binlog について簡単に紹介しましたが、データを変更する場合、これらの変更を保存して実装しますが、1 つは物理ログ、もう 1 つは論理ログです。では、彼らはどのようにして修正プロセスを実行したのでしょうか?

今実行する update ステートメントがあるとします。update from table_name set c=c 1 where id=2、実行プロセスは次のとおりです。

最初にレコードを見つけます。 with id=2 ;
エグゼキューターはエンジンによって与えられた行データを取得し、この値に 1 を加えて新しいデータ行を取得し、エンジンインターフェイスを呼び出してこの新しいデータ行を書き込みます。
実行者は、この操作のバイナリログを生成し、そのバイナリログをディスクに書き込みます。
実行者は、エンジンのコミットトランザクションインターフェイスを呼び出し、エンジンは書き込まれたばかりの REDO ログをコミット状態に変更し、更新が完了します。

#概略図は次のとおりです:

MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターするこれにより redolog の書き込みが分割されます。準備とコミットのプロセスは 2 フェーズコミットと呼ばれます。

redolog と binlog はどちらもトランザクションのコミットステータスを表すために使用できます。2 フェーズコミットは 2 つの状態の論理的な一貫性を維持するために使用されます。 2 フェーズコミットを使用せず、一方を最初に記述し、次にもう一方を記述した場合、問題が発生する可能性があります。

現時点では、更新はまだ例として使用されています。現在の id=2 で、フィールド c=0 があると仮定します。次の状況をそれぞれ分析します:

最初に redolog を書き込み、次に binlog を書き込みます redolog が最初に書き込まれると仮定します。完了しましたが、binlog はまだ書き込まれていません。書き終えたとき、MySQL が突然例外に遭遇し、再起動されました。 redolog は以前に書き込まれているため、システムの再起動後も変更されたレコードがまだ存在するため、リカバリ後のこの行の c の値は 1 になります。ただし、システムが再起動されたため、このレコードはバイナリログに存在しません。後でログをバックアップすると、このステートメントは保存されたバイナリログには存在しません。次に、このバイナリログを使用して一時ライブラリを復元する必要がある場合、このステートメントのバイナリログが失われているため、今回は一時ライブラリは更新されないことがわかります。復元された行の c の値は 0 です。元のライブラリの値と同じですが、異なります。

最初に binlog を書き込み、次に redolog を書き込みます。最初に binlog を書き込み、次に redolog を書き込むときにシステムを再起動します。再起動後、redolog には c を変更した記録はなく、この時点では c の値は 0 のままです。ただし、binlog には「c を 0 から 1 に変更する」というログが記録されています。そのため、後で binlog を使用して復元すると、トランザクションが 1 つ増えてしまい、復元された行の c の値は 1 となり、元のデータベースの値とは異なります。

したがって、要約すると、最初にログが書き込まれ、次に別のログが書き込まれると、データベースのステータスは、binlog を使用して復元されたライブラリのステータスと一致しなくなります。

3. undo log

undolog は主に、特定の行レコードが変更される前の状態を記録するために使用され、変更前のデータを記録します。この場合、トランザクションがロールバックされると、undolog を通じてレコードをトランザクションが開始される前の状態に復元できます。トランザクションの原子性と耐久性も undolog によって実現されます。アンドゥログは主にデータの論理的な変更を記録します。たとえば、INSERT ステートメントは DELETE アンドゥログに対応します。各 UPDATE ステートメントについては、反対側の UPDATE アンドゥログに対応するため、エラーが発生したときにロールアップできます。トランザクション前のデータ状態に戻ります。同時に、データ回復を実行するときに、binlog および redolog と組み合わせて使用され、データ回復の正確性を保証します。

アンドゥログの機能プロセスは次のとおりです:

MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする

変更を開始し、変更したデータをメモリに保存します;
アンドゥログをディスクに保存します;
データページをディスクにフラッシュして戻します;
トランザクションコミット;

redolog と同様に、undolog はデータページの前にディスクにフラッシュバックする必要があることに注意してください。データをリカバリするときに、アンドゥログが完了している場合は、アンドゥログに基づいてトランザクションをロールバックできます。

トランザクションでは、同じデータが複数回変更される可能性があるため、各変更前の記録をアンドゥログに記録する必要がありますか?この場合、アンドゥログのログ量が多くなりすぎるため、この時にリドログが活躍することになります。トランザクション内で同じレコードが変更された場合、undolog はトランザクション開始前の元のレコードのみを記録し、このレコードが再度変更されると、redolog はその後の変更を記録します。データのリカバリ中、redolog はロールフォワードを完了し、undolog はロールバックを完了し、この 2 つが相互に連携してデータのリカバリを完了します。
MySQL の 3 つの主要なログ: binlog、redo ログ、undo ログを完全にマスターする
もう 1 つの機能は MVCC マルチバージョンコントロールチェーンです。この記事を参照してください
MySQL の MVCC 実装原理