ロギング MySQL ロギング モジュール

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

目次

1. はじめに

2. REDO ログ

3. ビンログ

4. 内部ワークフロー

---

# #MySql 学習コラム

1. MySQL インフラストラクチャの詳細説明

2. MySQL インデックスの基礎となるデータ構造とアルゴリズム

3. MySQL5.7 ではバイナリログ ログが有効になります、およびデータ回復の簡単な例

4. MySQL ログ モジュール

1. はじめに

MySQL には 2 つの重要なログ モジュールがあります:

redo ログ (やり直しログ) および binlog (アーカイブ ログ) 。

redo ログは InnoDB ストレージ エンジン層のログ、binlog は MySQL Server 層が記録するログで、どちらも特定の操作を記録するログですが、記録の形式が異なります。

2. redo ログ

redo ログ: (redo ログ) ファイルとも呼ばれ、トランザクション操作の変更を記録するために使用されます。記録される内容は

トランザクションが送信されたかどうかに関係なく、データ変更後の値が記録されます。 メディア障害が発生した場合、REDO ログ ファイルが役に立ちます。データベースの電源が失われると、InnoDB ストレージ エンジンは REDO ログを使用して電源喪失前の時点に復元し、整合性を確保します。データの。

レコードを更新する必要がある場合、InnoDB エンジンはまずレコードを REDO ログに書き込み、メモリを更新します。この時点で更新は完了します。

InnoDB エンジンは、適切なタイミングでこの操作レコードをディスクに更新します。この更新は通常、更新効率を高めるためにシステムが比較的アイドル状態のときに完了します。

これには

WAL それが Write-Ahead Logging テクノロジー、彼の鍵となります。ポイントは、 最初にログを書き込み、次にディスクに書き込みます。 InnoDB の REDO ログはサイズが固定されており、たとえば 4 つのファイルのセットとして構成され、各ファイルのサイズが 1GB の場合、合計 4GB の操作を記録できます。

REDO ログは、次の図に示すように最初から書き込みを開始し、最後に到達すると最初に戻ってループして書き込みます。

write pos

はカレントレコードの位置で、書き込み中に後方に移動し、ファイルNo.3の最後まで書き込んだ後リターンします。ファイルNo.0の先頭まで。

チェックポイント

は消去する現在位置であり、これも逆方向に移動して循環します。レコードを消去する前に、レコードをデータファイルに更新する必要があります。

write pos

と

check point の間の領域は未使用の部分であり、新しい操作を記録するために使用できます。 write pos

が

check point に追いついた場合、REDO ログ レコードがいっぱいであることを意味します。現時点では、新しい更新は実行できません。最初にいくつかのレコードを停止して消去するには、チェックポイントを押します。 REDO ログを使用すると、InnoDB はデータベースが異常に再起動した場合でも、以前に送信されたレコードが失われないことを保証できます。この機能は クラッシュ セーフ

と呼ばれます。

REDO ログを使用する理由

データベースに対して DML 操作を実行し、実行された SQL をディスクに直接書き込む場合、書き込みの同時実行数が大きい場合、ディスクへのデータ書き込みに対する圧力が一定の影響を及ぼします。

操作を挿入し、現在の非リーフ ノードの 1 ページに不十分なデータがあることが判明した場合は、ページング アルゴリズムを実行する必要がありますが、効率が低くなります;

REDO ログを使用する場合ログを作成するには、最初に「転送ステーション」を介して DML 操作をログに書き込み、次に空いたときに

チェック ポイント

を介してディスクに書き込むと、効率が大幅に高くなります。

MySQL 設定 Redo ログ

• 書き込み時の innodb_log_buffer_size のサイズ: (デフォルトは 8M)
• innodb_log_file_size REDO ログ ファイルのサイズ。
• innodb_log_files_in_group は、REDO ログ ファイル グループ内のファイルの数を指定します。デフォルトは 2
• innodb_mirrored_log_groups は、ログ ミラー ファイル グループの数を指定します。デフォルトは 1
• innodb_log_group_home_dirログ ファイル グループの場所を指定します。パス (デフォルトは ./) は、データベースのデータ ディレクトリにあることを意味します。
• #innodb_flush_log_at_trx_commitコミット設定時にログ バッファ内のログをログ ファイルに記録します (値 0、1、2) デフォルト 1

#3.binlog

REDO ログは InnoDB エンジンに固有のログであり、サーバー層にも

binlog (アーカイブ ログ) と呼ばれる独自のログがあります。

ログが 2 つあるのはなぜですか?

MySQL には最初から InnoDB エンジンがなかったからです。 MySQL 独自のエンジンは MyISAM ですが、MyISAM にはクラッシュセーフ機能がなく、binlog ログはアーカイブにのみ使用できます。

InnoDB は、プラグインの形式で MySQL を導入した別の会社です。binlog のみに依存するとクラッシュ セーフ機能がないため、InnoDB は別のログ システム、つまり REDO ログを使用して ## を実現します。 # クラッシュセーフ

機能。 2 つのログには次の 3 つの違いがあります。

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

• redo ログは、「
• 特定のデータ ページで行われた変更内容を記録する物理ログです。」; binlog は、このステートメントを記録する論理ログです。 「#ID=2 の行の c フィールドに 1 を追加する」などの独自のロジック。 REDO ログはループで書き込まれ、スペースは常に使い果たされますが、binlog は追加で書き込むことができます。 「追加書き込み」とは、binlog ファイルが特定のサイズに達した後、次のファイルに切り替わり、前のログを上書きしないことを意味します。
• 4. 内部ワークフロー

テーブル更新ステートメントを例として、エグゼキューターと InnoDB エンジンの内部ワークフローを見てみましょう。 # #

mysql> update T set c=c+1 where ID=2;

下の図に示すように、明るいボックスは InnoDB 内で実行されることを示し、暗いボックスは実行プログラムで実行されることを示します。

エグゼキュータはまずエンジンを探して行 ID=2 を取得します。 ID が主キーであり、エンジンはツリー検索を直接使用してこの行を見つけます。 ID=2 行が配置されているデータ ページがすでにメモリ内にある場合は、そのデータ ページが直接エグゼキュータに返されます。それ以外の場合は、ディスクからメモリに読み取ってから返す必要があります。

エグゼキューターは、エンジンによって指定された行データを取得し、この値に 1 を加算します。たとえば、以前は N でしたが、現在は N 1 になり、新しいデータ行を取得して、エンジン インターフェイスを使用して、この新しいデータ行を書き込みます。

• エンジンは、この新しいデータ行をメモリに更新し、更新操作を REDO ログに記録します。この時点で、REDO ログは準備状態になります。次に、実行が完了し、いつでもトランザクションを送信できることを実行者に通知します。
• エグゼキュータは、この操作のバイナリログを生成し、バイナリログをディスクに書き込みます。
• エグゼキューターはエンジンのコミット トランザクション インターフェイスを呼び出し、エンジンは書き込まれたばかりの REDO ログをコミット状態に変更し、更新が完了します。
• 最後の 3 つのステップは少し「循環」しているように見えます。REDO ログの書き込みは、準備とコミットの 2 つのステップに分かれています。実際、これは「
• 2 段階」です。専念＃ ＃＃＃＃＃"。

ログに「2 フェーズ コミット」が必要なのはなぜですか?これは矛盾による証明で説明できます。

REDO ログと binlog は 2 つの独立したロジックであるため、2 段階の送信が必要ない場合は、最初に REDO ログを書き込んでから binlog を書き込むか、その逆の順序を採用する必要があります。前の update ステートメントを例として使用して、これら 2 つの方法にどのような問題があるかを見てみましょう。 ID=2 の現在の行で、フィールド c の値が 0 であると仮定します。また、更新ステートメントの実行中、最初のログが書き込まれた後、2 番目のログが書き込まれる前にクラッシュが発生すると仮定します。ログが書き込まれます。何が起こるでしょうか? 1.

最初に REDO ログを書き込み、次に binlog を書き込みます。

REDO ログが終了したとき、バイナリログが終了する前に、MySQL プロセスが異常に再起動したとします。 REDO ログが書き込まれた後は、システムがクラッシュしてもデータを復元できるため、回復後のこの行の c の値は 1 になります。

しかし、バイナリログが完了する前にクラッシュしたため、このステートメントは現時点ではバイナリログに記録されませんでした。したがって、後でログをバックアップするときに、このステートメントは保存されたバイナリログには含まれません。

次に、このバイナリログを使用して一時ライブラリを復元する必要がある場合、このステートメントのバイナリログが失われているため、今回は一時ライブラリは更新されず、復元された行の c の値は次のようになります。 0、元と同じ ライブラリの値が異なります。

2. 最初に binlog を書き込み、次にログをやり直します。 binlog の書き込み後にクラッシュが発生した場合、REDO ログはまだ書き込まれていないため、クラッシュ回復後のトランザクションは無効になるため、この行の c の値は 0 になります。

しかし、binlog には「Change c from 0 to 1」というログが記録されています。そのため、後で binlog を使用して復元すると、トランザクションが 1 つ増えてしまい、復元された行の c の値は 1 となり、元のデータベースの値とは異なります。

「2 フェーズ コミット」が使用されていない場合、データベースの状態は、ログを使用して復元されたライブラリの状態と一致しない可能性があることがわかります 。

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

以上がロギング MySQL ロギング モジュールの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。