はじめに MySQL ログ REDO ログと binlog

無料学習の推奨事項: mysql ビデオ チュートリアル

#序文

MySQL を使用したことのあるプログラマーであれば、多かれ少なかれ、REDO ログ (REDO ログ) と binlog (アーカイブ ログ) について聞いたことがあるでしょう。 。今日は、これら 2 つのログの用途と違いを共有しましょう。

簡単に言えば、REDO ログは InnoDB 固有のログであり、他のストレージ エンジンを使用すると、REDO ログは存在せず、binlog のみになります。

Binlog は MySQL のサーバー層のログで、どのストレージ エンジンを使用しても、binlog が存在します。では、なぜ REDO ログと binlog が必要なのでしょうか?たった 1 つの binlog だけですべてを解決することはできないでしょうか?次に、REDO ログと binlog の違いを詳しく見てみましょう。

redo log

MySQL では、ステートメントを更新する場合は、

update T set name = 'god のような更新条件を指定する必要があります。 -jiang' (id=6

)。通常、id=6 のステートメントが最初にクエリされ、次に更新操作が実行されます。 更新の数が 100、1,000、さらには 10,000 の場合、各更新をディスクに書き込む必要があります。この問題を解決するために、MySQL の設計者は WAL テクノロジーを使用してこの問題を解決しました。 WAL の完全な名前は

Write Ahead Logging

です。これは、最初にログを書き込み、次にディスクに書き込むことを意味します。 具体的な操作: レコードを更新する必要がある場合、InnoDB エンジンはまずレコードを REDO ログに書き込み、メモリを更新します。この時点で更新は完了します。同時に、InnoDB エンジンは、適切なタイミング (システムがアイドル状態のとき) にこの操作レコードをディスクに更新します。この更新は、多くの場合、システムが比較的アイドル状態のときに行われます。

しかし、REDO ログのサイズは固定されており、常に無限に書き込むことは不可能です。MySQL がどのように行うかを見てみましょう。

write pos は、書き込み中に後方に移動する現在のレコードの位置です。チェックポイントは消去する現在位置であり、これも逆方向に移動して循環しますので、レコードを消去する前にデータファイルにレコードを更新する必要があります。

書き込み位置とチェックポイントの間の緑色の部分は、新しい操作を記録できることを示します。書き込み pos がチェック ポイントに追いついた場合、REDO ログがいっぱいであることを意味します。この時点では、新しい操作を続行できません。いくつかのレコードを停止して消去し、チェック ポイントを戻す必要があります。

REDO ログを使用すると、InnoDB はデータベースが例外を検出して再起動した場合でも、以前に送信されたトランザクションが失われないことを保証できます。この機能は

クラッシュ セーフ

とも呼ばれます。 上記は REDO ログの概要です。これを読んだ後、MySQL を半月以内に任意の秒の状態に復元できるかどうかを会社の DBA 同僚に尋ねてみてください。答えは間違いなく「はい」です。 , これもすべてREDOログのおかげです。

binlog

MySQL 全体を見ると、実際には 2 つの層に分かれており、1 つはサーバー層、もう 1 つはストレージ エンジン層です。上で説明した REDO ログは InnoDB エンジンに固有のログですが、binlog はサーバー層に属するログであり、アーカイブ ログとも呼ばれます。

REDO ログと binlog の違い

REDO ログは InnoDB エンジンに固有であり、binlog は MySQL のサーバー層によって実装されており、使用できます。すべてのエンジンによる

• REDO ログは、「XXX データ ページで XXX の変更が行われました」を記録する物理ログです。binlog は、元のロジックを記録する論理ログであり、そのレコードは対応するものです。 SQL文
• REDOログはループで書かれていて確実に容量不足になるので、書き込みposとチェックポイントを一致させる必要がある; binlogは追加で書き込まれ、それが終わったら次のログに切り替わる特定のサイズに達すると、以前のログは上書きされません

単純な更新ステートメントを通じてエグゼキューターと InnoDB エンジンの内部プロセスを示します

update T set name = 'god-jiang' where id = 6

エグゼキューターを使用して、InnoDB エンジンから id=6 のレコードを取得し、それをメモリにロードします。

1. エグゼキューターは、エンジンから返された結果を取得し、名前を「god-jiang」に変更します。そして、ストレージ エンジン インターフェイスを再度呼び出して新しいデータを書き込みます。
2. エンジンは新しいデータをメモリに更新し、同時にこの更新操作を REDO ログに書き込みます。このとき、REDO ログは準備状態の
3. 実行プログラムはこの操作のバイナリログを生成し、そのバイナリログをディスクに書き込みます。
4. 実行プログラムはエンジンを呼び出します。トランザクションインターフェイスを送信し、先ほど書き込まれたREDOログを変更します。

#対応するフローチャート

最後に、なぜ REDO ログに書き込むと、更新が完了するのか準備状態で、バイナリログに書き込むとコミット状態に変わりますか?実際、このプロセスは「2 段階提出」と呼ばれます。

2 フェーズ送信

実際、REDO ログと binlog の両方を使用してトランザクション送信のステータスを表すことができ、2 フェーズ送信はこれらを維持することです。論理的に一貫した 2 つの状態。

例: update T set name = 'god-jiang' where id = 62 フェーズ提出がないとどうなりますか?

最初に REDO ログを書き込み、次に binlog を書き込みます。 REDO ログを書き込んだ後、binlog がまだ書き込まれておらず、この時点で MySQL が異常に再起動したとします。 REDOログが書き込まれているため、システムをリストアする際はname=‘god-jiang’とします。ただし、binlog は書き込まれていないため、binlog にはこのステートメントは記録されません。この時点で binlog を使用してデータを復元すると、復元された名前は元の値となり、REDO ログとは異なります。

同様に、最初に binlog を書き込み、次に redo ログを書き込んだ場合も、2 つのログによって復元されたデータが異なることがわかります。この不一致は、オンラインでのマスターとスレーブの不一致につながります。

概要

• REDO ログはクラッシュ セーフ機能を保存し、MySQL が異常に再起動してデータが失われないようにします。
• binlog は、対応する SQL ステートメントを記録でき、MySQL が異常に再起動したときにデータが失われないようにすることもできます。
• トランザクションの 2 段階の送信により、データの論理的一貫性を維持できます

##関連する無料学習の推奨事項 :mysql データベース(ビデオ)

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