MySQLのいくつかのログ
序文
MySQLにはいくつかのログファイルがあります。
- REDOログREDOログ
- ログのロールバックログを元に戻す
- binlogバイナリログ
- エラーログエラーログ
- 遅いクエリログ遅いクエリログ
- 一般的なログ一般的なクエリログ
- リレーログ
焦点の程度に応じて、ここにbinlog、REDOログ、およびUNDOログの簡単な紹介があります
最初に写真を見てみましょう。記事を読んだ後、この写真に再度アクセスできます。自分で描いて、さらに完全なものを追加することもできます。
binlog
マスタースレーブ同期データは、通常、それを介して実現されます。これは、MySQLサーバー層によって維持されないバイナリログです。InnoDBエンジンのREDO / UNDOログとはまったく異なるログです。主に、MySQLデータを更新するSQLステートメントを記録するために使用されます。更新し、「トランザクション」を使用します「フォームはディスクに保存されます
主な機能は次のとおりです。
- レプリケーション：MySQLマスタースレーブレプリケーションはマスター側でbinlogを開始し、マスターはバイナリログをスレーブに渡して再生し、一貫したマスタースレーブデータの目標を達成します。
- データ復旧：MySQLbinLogツールを介してデータを復旧します
- 増分バックアップデータ
知識のポイント：
- Binlogは、SelectやShowなどのデータを変更しないステートメントを記録しません。
- binlogは、ログ内のパスワードを書き換えて、プレーンテキストで表示されないようにします
- MySQL8以降のバージョンはbinlogの暗号化を選択できます
- 特定の書き込み時間：トランザクションが送信されると、データベースはbinlogキャッシュをbinlogファイルに書き込みますが、fsync（）操作は実行しません。つまり、ファイルの内容をOSキャッシュに書き込むだけで、構成fsyncに従って実行します。
- 削除時間：保持時間はパラメーターexpire_logs_daysで構成されます。これは、生成時間がexpire_logs_daysで構成された日数を超えると、非アクティブなログファイルが自動的に削除されることを意味します。
フォーマット：
binlogログには、行、ステートメント、および混合の3つの形式があります。my.cnf構成ファイルを
set global binlog_format='ROW/STATEMENT/MIXED'
使用してshow variables like 'binlog_format'変更でき、binlog形式はコマンドを使用して表示できます。
行形式
行形式は、レコードの変更された詳細のみを保存し、SQLステートメントのコンテキスト関連情報は記録しません。MySQLの新しいバージョンはデフォルトで行形式になっています。
1.その利点は次のとおりです。
データの各行の変更の詳細を非常に明確に記録でき、コンテキスト情報を記録する必要がなく、特定の状況下でトリガーされ、正しくコピーできないストアドプロシージャ、関数、またはトリガー呼び出しの問題。状況を複製することができ、データベースからのログの再生効率を高め、データベースからのデータの一貫性を確保できます。
2.欠点は
、実行されたすべてのステートメントが各行の変更の詳細とともにログに記録されるため、大量のログコンテンツが生成される可能性があり、干渉コンテンツが増えることです。たとえば、更新ステートメントが複数のレコードを変更した場合、binlogの各変更が記録されます。これにより、特にテーブル構造の変更により、alter tableなどのステートメントを実行するときに、大量のbinlogログが発生します。レコードが変更されると、テーブルのすべてのレコードがログに記録されます。これは、テーブルの再構築に相当します。
ステートメント形式
データを変更する各SQLは、binlogに記録されます。
1.利点は次のとおりです。
実行されたステートメントとコンテキストの詳細を記録するだけでよく、各行の変更を記録する必要はありません。行形式を超える変更レコードがある場合は、binlogログの量を大幅に減らすことができます。 IO、およびパフォーマンスを向上させます。
また、リアルタイムの復元にも使用できます。
マスターとスレーブのバージョンは異なる場合があり、スレーブサーバーのバージョンはマスターサーバーのバージョンよりも高い場合があります。
2.欠点は
、SQLステートメントをスレーブで正しく実行できるようにするために、コンテキスト情報を記録して、スレーブ側とマスター側ですべてのステートメントを実行したときに同じ結果が得られるようにする必要があることです。
さらに、マスタースレーブレプリケーション中に、前回スレーブでマスター結果の不整合に表示されるスリープやエラーストレージプロセスなどの機能があります。行ごとに記録された各行の変更の詳細と比較すると、この不整合は決して発生しません。起こります。
混合フォーマット
これは、上記の2つの形式を組み合わせたものです。
前の比較の後、行とステートメントには独自の利点があることがわかります。SQLステートメントから選択できる場合は、パフォーマンスとエクスペリエンスが向上する可能性があります。混合は、2つの形式の組み合わせです。
マスタースレーブレプリケーションレプリケーション
中のMySQLの最も重要な機能の1つである、MySQLクラスターの高可用性、負荷分散、および読み取り/書き込み分離は、すべてレプリケーションに基づいています。コピー手順は次のとおりです
。1。マスターはデータの変更をbinlogに記録します。
2.スレーブのIOプロセスはマスターに接続し、指定されたログファイルの指定された場所または開始位置からログコンテンツを要求します。3。
マスターがスレーブのIOプロセスから要求を受信した後、ベースへのコピーバックを担当するIOプロセス要求情報がログの指定された場所にのみ送信された後のログ情報は、スレーブのIOプロセスに返されます。ログに含まれる情報に加えて、返される情報には、binlogファイルの名前と、返された情報がマスターに到達したbinlogの場所も含まれます。
4.スレーブIOプロセスは情報を受信した後、受信したログコンテンツをスレーブ側のリレーログファイルの最後に追加し、読み込まれたマスター側のbinlogのファイル名と場所を記録します。次回のmasterinfoファイル一人で行くときは、ログの内容をクリアして、binlogのどの位置から開始するかをマスターに指示できます。
5.スレーブのSQLプロセスは、新しく追加されたコンテンツがリレーログに追加されたことを検出すると、すぐにリレーログのコンテンツを分析して、マスター側で直接実行されると実行可能コンテンツになり、それ自体で実行されます。
元に戻すログ和やりログ
元に戻すログとやり直しログはどちらもMySQLデータベースレベルのログではなく、InnoDBストレージエンジンからのログです。この2つの機能は密接に関連しており、トランザクションの分離はロックによって実現され、アトミック性、一貫性、および耐久性はデータベースのREDOログとUNDOログによって完了します。やり直しログは、やり直しログとも呼ばれ、トランザクションの耐久性を確保するために使用され、取り消しログは、トランザクションとMVCCのアトミック性を確保するために使用されます。
ロドログ
- 揮発性REDOログバッファと永続REDOログファイルの2つの部分が含まれています
- REDOログファイル（REDOログファイル）に保存
- 永続性を維持する
- ページ操作
機能はほとんどのリレーショナルデータベースと同じです。InnoDBはデータファイルへの物理的な変更を記録し、ログが常に最初になることを保証します。これはいわゆるWALであり、前のREDOログがディスクに書き込まれる前にデータファイルは永続化されます。REDOログはブロック単位で順番に書き込まれるため、パフォーマンスが向上します。
REDOログは2つの部分で構成されます。1つはメモリ内のREDOログバッファであり、簡単に失われます。もう1つは、永続的なREDOログファイルです。REDOログは、トランザクションがコミットされているかどうかに関係なく、トランザクション操作の変更を記録し、データの変更された値を記録します。
書き込みプロセスでは、ステートメントが実行されると、InnoDBエンジンは新しいレコードをREDOログログに書き込み、メモリを更新します。更新が完了すると、ステートメントが実行されても、アイドル状態または次のようになります。 set更新戦略は、REDOログの内容をディスクに更新します。
REDOログのストレージはブロックに保存され、各ブロックのサイズは512バイトです。ディスクセクターと同じサイズで、ブロック書き込みがアトミック操作であることを保証できます
ログを元に戻す
- 挿入元に戻すログ（挿入、挿入はそれ自体のトランザクションにのみ表示され、他のトランザクションには影響しません）と更新元に戻すログ（更新/削除）に分けられます
- データベースのUNDOセグメント（セグメント）に保存されます
- ロールバック用
- MVCCに使用され（非ロック読み取りを実現するため）、レコードの行を読み取るときに、他のトランザクションによって既に占有されている場合、前のバージョンは元に戻すことによって読み取られます
- 原子性を維持する
- 行操作（行レコードを特定のバージョンにロールバック）
- 元に戻すは論理ログであり、ステートメントまたはトランザクションを実行する前にデータベースロジックをに復元するだけです。
データが変更されると、やり直しが記録されるだけでなく、対応する取り消しも記録されます。何らかの理由でトランザクションが失敗またはロールバックした場合は、取り消しを使用してロールバックできます。
元に戻すログとやり直しログの記録は、物理ログが同じではなく、論理ログです。レコードが削除されると、対応する挿入レコードが元に戻すログに記録され、逆に、レコードが更新されると、対応する更新レコードが記録されると見なすことができます。
行バージョン管理に適用すると、元に戻すログによっても実行されることがあります。行の読み取りが他のトランザクションによってロックされている場合、元に戻すログから行レコードの以前のデータを分析し、行バージョン情報を提供して、ユーザーが許可することができます。非ロックの一貫した読み取りを実現します。
元に戻すログはセグメントごとに記録され、各元に戻す操作は、記録時に元に戻すログセグメントを占有します。
さらに、元に戻すログも永続的な保護を実現する必要があるため、元に戻すログはREDOログも生成します。
トランザクションがコミットされると、元に戻すログは後で使用される可能性があるため、InnoDBは元に戻すログをすぐに削除しません。たとえば、分離レベルが繰り返し読み取り可能な場合、トランザクションは、トランザクションの開始時にコミットされた最新の行バージョンを読み取ります。トランザクションが終了していない限り、行バージョンを削除することはできません。つまり、取り消しログを削除することはできません。
トランザクションがコミットされた後、元に戻すログをすぐに削除することはできませんが、クリーンアップするためにリンクリストに配置されます。パージスレッドは、元に戻すテーブルの前のトランザクションの前のバージョン情報を使用して、他のトランザクションがあるかどうかを判断します。元に戻すことがクリーンアップできるかどうかを判別するセグメント。ログ用のログ・スペース。
MySQL 5.7より前は、UNDOログは共有表スペースに保管されていたため、表スペースの占有率を大幅に増やすことができます。5.7以降は、構成オプションを使用して別の表スペースに保管できます。
添付ファイル：
slowクエリログのいくつかの構成パラメータ：
slow_query_log状態の
slowクエリslow_query_log_file遅いクエリログの保存場所（このディレクトリには、MySQL実行アカウントの書き込み可能な権限が必要です。通常はMySQLデータストレージディレクトリに設定されます）
long_query_timeクエリがレコードを超える秒数
log_queries_not_using_indexes：クエリが低速クエリログに記録された未使用のインデックス（オプション）パラメータは、構成ファイルを介して変更でき、データベースのsETキーワードで設定することもできます。