MySQL ログの包括的なガイド

この記事では、mysql に関する関連知識を提供します。主にログに関連する問題を紹介します。Mysql のログ システムは、いつクラッシュしてもデータが失われないようにします。鍵となるのは、次の点です。合わせて、皆さんのお役に立てれば幸いです。

推奨学習: mysql ビデオ チュートリアル

Mysql のログ システムは、いつクラッシュしてもデータが失われないことを Mysql が保証します。 Key

ご存知のとおり、Mysql は永続的なデータベースです。データが失われないように、すべてのデータはハードディスクに永続化されます。

Mysql は、データが失われないようにします。

• トランザクションのクラッシュの前後に関係なく、いつでもデータの状態を復元できること

• トランザクション中のクラッシュは、トランザクションがサブミットされる前の状態に復元できます。

トランザクションがサブミットされた後のクラッシュ

#MySQL は上記を保証します この 2 点の鍵は、UNDO ログ、REDO ログ、binlog の 3 つのログによって実現されます。

#undo ログ ロールバック ログ

undo ログは Mysql Roll ログの戻り値であり、古いバージョンのデータを保存します

Main function

古いバージョンのデータを保存しますRead View と連携し、隠しフィールドは Mysql スナップショット読み取りを実装します

トランザクション実行時にトランザクション開始前のバージョンにロールバックするために使用されます失敗

#Undo ログの種類

Undo ログには 2 つのタイプがあります#挿入コマンドの場合、undoログには、新しく追加されたレコードの主キーが記録されます。ロールバック中は、元に戻すログの主キーに基づきます。対応するレコードを削除するだけです。更新/削除コマンドの場合、元に戻すログには古いデータが記録されます変更されたレコードの

Mysql のデータの各行には、最新に変更された現在のデータ行があります。トランザクション ID とロールバック ポインタの 2 つのフィールドです。データ行が変更されると、アンドゥ ログ ポインタは古い行を指します。新しく生成されたデータ行のロールバック ポインタは、現在の UNDO ログ ポインタを指します。古いデータ行は

を指しました。元に戻すときの同時実行性の問題を回避するためです。ログ ポインタが変更されると、Mysql は変更前のアンドゥ ログ ポインタに排他的ロックを追加して、アンドゥ ログの正しい書き込みを保証します。

##undo ログ いつ削除するか

• undo ログは、トランザクションが送信されない場合に、トランザクションが開始される前の状態にスムーズにロールバックできるようにするために使用されます。トランザクションが送信されると、アンドゥ ログはその機能を失い、削除する必要があります。
  アンドゥ ログは Mysql 削除のパージ スレッドを担当し、パージは定期的にアンドゥ ログ内の delete_bit フラグをチェックします。このフラグはトランザクションがコミットされた後、true に設定されます。パージ スレッドが true のレコードを見つけた場合、それを削除する責任があります。

REDO ログ REDO ログ

REDO ログは、 MySQL の物理ログ。特定のデータ ページが実行する操作の種類を記録します。

#REDO ログの役割

送信されたトランザクションによるデータの変更を記録する責任を負います。記録された内容はおそらく、テーブル x

のページ y の z オフセットの更新です。Mysql が待機する必要がないようにします。トランザクションのコミット時にディスクに永続化するデータ。REDO ログをディスクに永続化するだけで済みます。

クリアされていない REDO ログの数は、ディスクがまだ消去されていないことを示します。フラッシュされたダーティ ページの数

データをディスクに永続化する代わりに REDO ログを永続化するためにトランザクションをコミットする理由

• データをディスクに永続化することはランダム IO プロセスです。そのため、Mysql はデータをキャッシュし、IO
  を削減するためにデータを一度にディスクに書き込む適切な機会を待つことを選択しますが、メモリ内のデータ キャッシュが失われるリスクがあるため、Mysql は永続化を選択します。 REDO ログ
• REDO ログはシーケンシャルに書き込まれ、ランダムな書き込みよりも永続性の効率が高く、REDO ログにはデータの変更が記録されます。REDO ログが存在する限り、 Mysql 再起動後にデータを復元可能
  InnoDB では、REDO ログは固定サイズの循環キューのような存在であり、各書き込みは最後尾の書き込み pos の位置から行われ、データを永続化する際のチェックポイントは
この設計の理由は、Mysql がクラッシュした後にキャッシュされたダーティ ページ データが失われるのを防ぐために REDO ログが存在するためです。 MySQL のデータはディスクに永続化されます。永続化部分の REDO ログは実際には役に立たないため、新しいデータを記録するためのスペースを解放できます

UNDO ログの違いおよびやり直しログ

UNDO ログはトランザクション実行中の古いデータのステータスを記録し、REDO ログはデータ更新後のステータスを記録します。

REDO ログは実際にトランザクションの永続性と一貫性を保証しますが、UNDO ログはトランザクションのアトミック性を保証します。トランザクション

binlog アーカイブ ログ

binlog は Mysql サーバー層によって実装されたログで、すべてのエンジンに共通です

関数

Binlog は、mysql の元のステートメントロジックを記録し、追加書き込みの形式で記録されるため、いつでも mysql のデータベースのデータ状態を復元するために使用できます

#だから Binlog と呼ばれますはアーカイブ ログです

同時に、binlog はマスター/スレーブ レプリケーションを実装するための Mysql の依存関係でもあります。スレーブ ライブラリは、メイン ライブラリから binlog 再生をコピーすることで、メイン ライブラリのデータ ステータスを同期します。 library

定義

最初にログをディスクに書き込み、次にデータをディスクに書き込みます。Mysql の書き込み操作はそうではありません。すぐにディスクに書き込まれますが、REDO を確実にするためにログが最初に書き込まれます。ログと binlog は両方ともディスクに保存され、その後、バックグラウンド スレッドがデータをハード ディスクに保存する機会を選択します。

最初にログをディスクに書き込む必要があるのはなぜですか

ダーティ ページのフラッシュはランダムな読み取りおよび書き込みプロセスであるため、ディスクに永続化する速度は明らかに遅くなります。 REDO ログ | binlog などのシーケンシャル書き込みと同じくらい高速なので、最初にメモリ内のデータを変更し、後で選択することを選択します。タイミングはディスクに非同期で永続化されます。

したがって、ダーティ ページが存在する期間中は、ディスクにフラッシュされていない場合、REDO ログ | binlog はデータの永続性を保証し、メモリ内のデータの停電や再起動を防ぎます。ページをディスクに書き込んでから削除する必要があります。すべてのページを削除して、次に使用するときに REDO ログを通じて復元してみてはいかがでしょうか。

ディスクからデータを読み取るたびにパフォーマンスを考慮するメモリに保存するには、REDO ログと比較して更新する必要があり、非常に非効率的です。

MySQL はダーティ ページをフラッシュしてディスクに書き込み、データ ページを確保します。メモリ内にある限り、返せる最新のデータである必要があります

##メモリ上にデータがない場合は、REDOログと比較することなく、ディスクから読み込むことで最新の正しいデータを確実に取得できます

binlog と redo ログの書き込みプロセス - WAL メカニズムの基本保証

binlog と redo ログは両方とも、ログの書き込みを 3 つのプロセス (キャッシュの書き込み、書き込み、同期) に分割します

トランザクションの実行、binlog および redo ログは、対応する割り当てられたキャッシュに書き込まれるため、トランザクションの送信時に一度にディスクに書き込むことができます。トランザクションが送信されます。write は、オペレーティング システムのページ キャッシュにデータを書き込みます。この時点では、データは実際にはファイルに書き込まれませんが、安全に保管するためにオペレーティング システムのキャッシュに渡されます。Mysql の場合この時点でプロセスがクラッシュしても、書き込まれたデータのこの部分は失われません。失われますが、オペレーティング システムのカーネル スレッドが、キャッシュされたデータのこの部分をディスクに書き込む責任を負います

#ただし、オペレーティング システムがクラッシュすると、データのこの部分は失われます。

最後に、mysql は手動で sync を呼び出し、ページ キャッシュに書き込まれたデータをハードディスクに保存します。書き込みが完了すると、データは正常に永続化されます。

• 最後の書き込みと同期のステップ mysql は、書き込み戦略を制御するための対応するパラメーターを提供します

REDO ログが制御されますinnodb_flush_log_at_trx_commit 経由

#0 に設定すると、トランザクションがコミットされるたびに、REDO ログが REDO ログ キャッシュにのみ残ることを意味します。

損失のリスクが最大です

• 1 に設定すると、各トランザクションがコミットされるたびに、REDO ログがディスクに直接保存されることを意味します

損失のリスクは最小限ですが、IO 使用量は大きくなります。

• 2 に設定すると、トランザクションがコミットされるたびに、 REDO ログはページ キャッシュにのみ書き込まれます
  ##IO 占有は集中され、最も IO を消費するディスクへの書き込みプロセスはオペレーティング システムに任せられます

Binlog はパラメータ sync_binlog によって制御されます

#sync_binlog=0 の場合、トランザクションが送信されるたびに、fsync ではなく書き込みのみが実行されることを意味します
sync_binlog=1 の場合は、トランザクションが送信されるたびに fsync が実行されることを意味します。

# sync_binlog=N(N>1) の場合、書き込みが実行されることを意味しますトランザクションが送信されるたびに実行されますが、N 個のトランザクションが蓄積された後でのみ fsync が実行されます。

• 2 フェーズ ログの送信

• 2 フェーズ ログとはsubmit

• REDO ログの送信プロセスは、準備とコミットの 2 つの段階に分かれています。binlog ログの送信は、これら 2 つの段階の真ん中にあります。

トランザクションが送信されると、REDO ログが最初に送信され、次に準備状態に入ります。その後、バイナリログの送信が完了すると、REDO ログはログのステータスをコミット送信済みに変更できます

2 段階のログ送信が必要な理由

これは、InnoDB エンジンのロールバック メカニズムに関連しています。InnoDB の REDO ログは、トランザクションの送信後にロールバックできません。バイナリ ログの送信に失敗した場合は、 REDO ログが送信された後に書き込まれた場合、2 つの不整合が発生します。ログの提出が必要です

時刻 A にデータベースがクラッシュするとします。これは、binlog が書き込まれておらず、REDO ログが送信されていないため、トランザクションは再起動後にロールバックされ、2 つのログは同じ状態のままです

期間の場合 B の場合 REDO ログのコミットフラグを判定する必要がある REDO ログにコミットフラグがあるかどうかを確認し、あればトランザクションに問題はなく、

• If redo ログ内のトランザクションに対応するコミット フラグがない場合は、バイナリ ログがチェックされます。バイナリログが完了し、コミット フラグがある場合、トランザクションが送信され、コミット フラグが再実行ログの後に追加されます。バイナログが不完全な場合はトランザクションをロールバックします。 #ここでは、2 段階のログ送信で発生したクラッシュが binlog 標準に基づいていることがわかります。その理由は、マスター/スレーブ レプリケーションが binlog に基づいているためです。

両方のログの整合性が保たれている場合チェックが必要です。メイン ライブラリがハングアップした場合、スレーブ ライブラリに切り替えるのに時間がかかります。binlog に基づいて、メイン ライブラリがハングアップした場合、binlog を直接使用してスレーブ ライブラリからデータを復元できます。それだけです。 、REDO ログの整合性をチェックする必要はありません
• #さらに、binlog は Mysql Server 層の共通ログであるため、binlog がベンチマークとして選択されます
  #2 段階のログ送信の欠点

ディスク IO の数が多い

#ログを送信する際、 REDO ログと binlog に対応するフラッシュ操作が多く、IO 数が多い

熾烈なロック競争
複数のトランザクションが送信される場合、ログ レコードはトランザクションの送信順序と一致し、ログ送信の相対的な順序を保証するためにロックが使用されます。

ただし、同時実行量が多いとパフォーマンスが低下します

• ##グループ送信メカニズム

#グループ送信メカニズムの役割

##エスケープしたトランザクションがある場合送信すると、複数のトランザクションのログが書き込みのためにマージされ、ディスク IO 操作が削減されます

グループ送信メカニズムの実装グループ送信メカニズムは、コミット プロセスを 3 つに分割します。シーケンスの書き込みを保証するためにロックを使用し、各プロセスのキューを維持し、ロックを使用します。

ロックを 3 つの段階に分割すると、トランザクションの送信プロセス全体をロックすることなく、ロックの粒度を減らすことができます

キューが空の場合 この時点で、キューに入った最初のトランザクションが後続のトランザクションのリーダーとなり、後続のトランザクションが操作の次のフェーズを完了するように導きます

フェーズ 1: フラッシュ フェーズ

: 複数のトランザクションが Enter キーを押します (ディスクをフラッシュせずに) バイナリ ログをキャッシュからファイルに順番に書き込みます

フラッシュ フェーズに入る最初のトランザクションが処理されますリーダーとして後続のトランザクションを主導します

• リーダー トランザクションはすべてを主導します トランザクションは REDO ログに対して書き込み fsync を実行します。つまり、REDO ログをディスクに書き込み、REDO ログの Propare フェーズを完了します。
  この段階で Mysql がクラッシュした場合、この一連のトランザクションは再起動後にロールバックされます

フェーズ 2:

sync

: binlog ファイルに対して fsync 操作を実行します ( (複数のトランザクションの binlog をまとめてディスクをフラッシュします)

フラッシュ ステージで binlog ファイルに binlog を書き込んだ後、ディスクをフラッシュする前に一定時間待機します。目的は、より多くのトランザクションの binlog を結合することです。トランザクションを実行し、消費量を削減するためにディスクをまとめてフラッシュします。#待機には時間制限と最大トランザクション制限があり、条件のいずれかが満たされると、バイナリ ログはすぐにフラッシュされます。ディスク

同期ステージは主に binlog のグループ送信を担当します。Mysql が現在のステージでクラッシュした場合、再起動後に REDO ログ レコードをフラッシュすることでトランザクションの送信を続行できます

この時点でバイナリログの送信が完了しているため、REDO ログに基づいてトランザクションを引き続き送信できます

フェーズ 3:

commit

: それぞれに対して InnoDB コミット操作を実行します。トランザクション

推奨される学習:

mysql ビデオ チュートリアル

以上がMySQL ログの包括的なガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。