MySQL ログの包括的なガイド-mysql チュートリアル-php.cn

この記事では、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 ログ

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

#REDO ログの役割

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

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

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

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

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

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 は、書き込み戦略を制御するための対応するパラメーターを提供します

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

損失のリスクが最大です

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

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

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

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

# 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 は 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 サイトの他の関連記事を参照してください。