MySQLの7種類のログの概要

MySQL には次のログ ファイルがあります。

1: 再実行ログ
2: ロールバックログ（元に戻すログ）
3: バイナリログ（binlog）
4: エラーログ
5: スロークエリログ
6: 一般クエリログ（一般ログ）
7: リレーログ

その中で、REDO ログとロールバック ログはトランザクション操作と密接な関係があり、バイナリ ログもトランザクション操作と一定の関係があります。これら 3 つのログは、MySQL でのトランザクション操作を理解する上で非常に重要です。

1. ログの再実行

効果：
トランザクションの耐久性を確保します。 REDO ログは、トランザクションが実行された後のステータスを記録し、データ ファイルに書き込まれていない、成功したトランザクションによって更新されたデータを回復するために使用されます。障害発生時にダーティ ページがディスクに書き込まれるのを防ぐため、MySQL サービスの再起動時に REDO ログに基づいてトランザクションをやり直し、トランザクションの永続性を実現します。

コンテンツ：
物理フォーマットログは物理データページの変更情報を記録し、そのREDOログはREDOログファイルの物理ファイルに順次書き込まれます。

いつ生成されるか:
トランザクションの開始後に、REDO ログが生成されます。REDO ログは、トランザクションがコミットされたときにディスクに書き込まれるのではなく、トランザクションの実行中に REDO ログ ファイルに書き込まれます。

リリース時:
対応するトランザクションのダーティ ページがディスクに書き込まれると、REDO ログの使命は完了し、REDO ログが占めていた領域を再利用可能 (上書き可能) になります。

対応する物理ファイル:
デフォルトでは、対応する物理ファイルは、データベースのデータ ディレクトリ内の ib_logfile1 と ib_logfile2 にあります。
innodb_log_group_home_dir は、ログ ファイル グループが配置されているパスを指定します。デフォルト値は ./ で、データベースのデータ ディレクトリ内にあることを意味します。
innodb_log_files_in_groupはREDOログファイルグループ内のファイル数を指定します。デフォルトは2です。

ファイルのサイズと数は、次の 2 つのパラメータによって構成されます。
innodb_log_file_size REDO ログ ファイルのサイズ。
innodb_mirrored_log_groupsはログミラーファイルグループの数を指定します。デフォルトは1です。

他の：
非常に重要な点は、REDO ログがいつディスクに書き込まれるかということです。前述したように、トランザクションが開始されると、ディスクへの書き込みは徐々に行われます。
トランザクション開始後、REDO ログが徐々に REDO ログ ファイルに書き込まれ、トランザクションがコミットされた後に必ずしも REDO ログ キャッシュに書き込まれないのは、REDO ログにバッファ領域 Innodb_log_buffer があるためです。Innodb_log_buffer のデフォルト サイズは 8M (ここでは 16M に設定) です。Innodb ストレージ エンジンは、まず REDO ログを innodb_log_buffer に書き込みます。

次に、InnoDB ログ バッファー内のログが次の 3 つの方法でディスクにフラッシュされます。

マスター スレッドは、Innodb_log_buffer の REDO ログ ファイルへのフラッシュを 1 秒に 1 回実行します。

各トランザクションはコミットし、REDO ログを REDO ログ ファイルにフラッシュします。

REDO ログ キャッシュの使用可能スペースが半分未満になると、REDO ログ キャッシュは REDO ログ ファイルにフラッシュされます。

このことから、REDO ログが複数の方法でディスクに書き込まれることがわかります。特に最初の方法では、REDO ログ ファイルへの Innodb_log_buffer は、マスター スレッドのスケジュールされたタスクです。

したがって、REDO ログのディスクへの書き込みは、必ずしもトランザクションがコミットされたときに行われるわけではなく、トランザクションの開始とともに徐々に開始されます。

さらに、「MySQL Technology Insider Innodb Storage Engine」(37 ページ) から元の文を引用します。

トランザクションがコミットされていない場合でも、Innodb ストレージ エンジンは 1 秒ごとに REDO ログ キャッシュを REDO ログ ファイルにフラッシュします。

これは知っておくべき重要なことです。なぜなら、最大規模のトランザクションであってもコミット時間が非常に短い理由をうまく説明できるからです。

2. ロールバックログ（元に戻すログ）

効果：
データの原子性を保証し、トランザクションが発生する前にデータのバージョンを保存します。このバージョンはロールバックに使用できます。また、マルチバージョン同時実行制御 (MVCC) による読み取り、つまりロックなしの読み取りも提供できます。

コンテンツ：
論理ログは、物理ページを操作するのではなく、元に戻す操作を実行するときにのみ、トランザクション前の状態にデータを復元します。これは、再実行ログとは異なります。

いつ生成されるか:
トランザクションが開始される前に、現在のバージョンが UNDO ログに生成されます。UNDO は、UNDO ログの信頼性を確保するために REDO も生成します。

いつリリースされますか:
トランザクションがコミットされた後、UNDO ログはすぐに削除されず、リンク リストに格納されてクリーンアップされます。パージ スレッドは、UNDO セグメント内のテーブルで前のトランザクションより前のバージョン情報を他のトランザクションが使用しているかどうかを確認し、UNDO ログのログ領域をクリーンアップできるかどうかを決定します。

対応する物理ファイル:
MySQL 5.6 より前では、UNDO テーブルスペースは共有テーブルスペースのロールバック セグメントに配置されます。共有テーブルスペースのデフォルト名は ibdata で、データ ファイル ディレクトリに配置されます。
MySQL 5.6 以降では、UNDO テーブルスペースを独立したファイルとして設定できますが、事前に設定ファイルで設定する必要があります。データベースの初期化後に有効になり、UNDO ログ ファイルの数は変更できません。データベースの初期化前に関連する設定が行われていない場合は、独立したテーブルスペースとして設定できません。

MySQL 5.7 以降の独立した UNDO 表領域の構成パラメータは次のとおりです。
innodb_undo_directory = /data/undospace/ – UNDO 独立テーブルスペースのストレージ ディレクトリ innodb_undo_logs = 128 – ロールバック セグメントは 128 KB です innodb_undo_tablespaces = 4 – 4 つの UNDO ログ ファイルを指定します 共有テーブルスペースが UNDO に使用される場合、この共有テーブルスペースには UNDO 情報が格納されるだけでなく、共有テーブルスペースのデフォルトは MySQL データ ディレクトリに設定され、そのプロパティはパラメーター innodb_data_file_path によって構成されます。

他の：
UNDO は、トランザクションが開始される前に保存された変更されたデータのバージョンです。UNDO ログが生成されると、トランザクションの永続性を保護するメカニズムに似た REDO ログも生成されます。
デフォルトでは、UNDO ファイルは共有テーブルスペース、つまり ibdatafile ファイルに保存されます。データベースで大規模なトランザクション操作が発生すると、大量の UNDO 情報が生成され、すべて共有テーブルスペースに保存されます。
したがって、共有表領域が非常に大きくなる可能性があります。デフォルトでは、UNDO ログが共有表領域を使用する場合、「拡張された」共有表領域は自動的に縮小されず、縮小することもできません。
そのため、MySQL 5.7 以降では「独立した UNDO テーブルスペース」の構成が非常に重要になります。

3. バイナリログ（binlog）

効果：
レプリケーションに使用されます。マスター スレーブ レプリケーションでは、スレーブ データベースはマスター データベースの binlog を使用して再生し、マスター スレーブ同期を実現します。
データベースのポイントインタイム復元に使用されます。

コンテンツ：
論理形式のログは、実行されたトランザクション内の SQL ステートメントとして簡単に考えることができます。
しかし、これは単なる単純な SQL 文ではなく、実行された SQL 文の逆の情報 (追加、削除、変更) を含みます。つまり、delete は delete 自体とその逆の insert に対応し、update は update が実行される前と後のバージョンの情報に対応し、insert は delete と insert 自体の情報に対応します。
mysqlbinlog を使用して binlog を解析すると、真実の一部が明らかになります。
したがって、binlog に基づいて、実際に binlog 内のログ レコードに依存する Oracle と同様のフラッシュバック機能を実現できます。

いつ生成されるか:
トランザクションがコミットされると、トランザクション内のすべての SQL ステートメント (1 つのトランザクションが複数の SQL ステートメントに対応する場合があります) が、特定の形式で一度に binlog に記録されます。
ここでの明らかな違いは、トランザクションがコミットされたときに、必ずしも REDO ログがディスクにフラッシュされるわけではないということです。トランザクションの開始後、REDO ログは徐々にディスクに書き込まれます。
したがって、大規模なトランザクションであっても、トランザクションの送信は非常に高速です。ただし、bin_log が有効になっている場合は、大規模なトランザクションの送信が遅くなる可能性があります。
これは、トランザクションがコミットされたときに binlog が 1 回書き込まれるためであり、テストを通じて検証できます。

リリース時:
binlog のデフォルトの保持期間は、expire_logs_days パラメータによって設定されます。つまり、非アクティブなログ ファイルの場合、生成時間が expire_logs_days で設定された日数を超えると、自動的に削除されます。

対応する物理ファイル:
設定ファイルのパスは log_bin_basename です。binlog ログ ファイルは指定されたサイズです。ログ ファイルが指定された最大サイズに達すると、ロールオーバーされ、新しいログ ファイルが生成されます。
各 binlog ログ ファイルは、統合されたインデックス ファイルを通じて整理されます。

他の：
バイナリログの機能の 1 つはデータベースを復元することです。これは redo ログと非常に似ています。多くの人が混同していますが、この 2 つは根本的に異なります。redo ログはトランザクションの永続性を保証するためのもので、トランザクション レベルです。一方、バイナリログは復元機能として、データベース レベルです (もちろん、トランザクション レベルに正確にすることもできます)。どちらも復元という意味ですが、データ保護のレベルは異なります。
異なる内容: redo ログは物理ログであり、データ ページの変更の物理的な記録です。一方、binlog は論理ログであり、単純に SQL ステートメントを記録するものと考えることができます。また、ログが生成される時間、ログをリリースできる時間、ログをリリースできるクリーンアップ メカニズムも完全に異なります。
データ回復の効率は、ステートメント論理ログ binlog よりも高くなります。
トランザクションがコミットされる際の redo ログと binlog の書き込み順序については、マスタースレーブレプリケーション (もちろん、ポイントインタイムリカバリのための binlog の使用も含まれます) 中にマスターとスレーブ間の一貫性を保証するために、厳密に一貫している必要があります。MySQL は、2 フェーズコミットプロセス、つまり redo ログと binlog の一貫性を通じてトランザクションの一貫性を実現します。理論上は、最初に redo ログが書き込まれ、次に binlog が書き込まれます。両方のログが正常にコミット (ディスクにフラッシュ) された場合にのみ、トランザクションが真に完了します。

4. エラーログ

エラー ログには、mysqld の起動と停止に関する情報と、サーバーの実行中に発生したエラーが記録されます。デフォルトでは、システム エラー ログ機能は無効になっており、エラー メッセージは標準エラー出力に出力されます。
ログ パスを指定するには、次の 2 つの方法があります。
1) my.cnfを編集し、log-error=[path]と記述します。
2) コマンドパラメータによるエラーログ mysqld_safe –user=mysql –log-error=[path] &

エラーログを表示するコマンド（以下を参照）

5. 一般的なクエリログ

一般ログには、クエリまたはコマンドが正しいか、構文エラーが含まれているかに関係なく、サーバーが受信したすべてのクエリまたはコマンドが記録されます。レコード形式は {Time、Id、Command、Argument} です。 MySQL サーバーはログを継続的に記録する必要があるため、一般ログをオンにするとかなりのシステム オーバーヘッドが発生します。 したがって、MySQL はデフォルトで一般ログをオフにします。

ログの保存方法を表示します: 'log_output' などの変数を表示します。

mysql> set global log_output='table' と設定すると、ログ結果は gengera_log というテーブルに記録されます。このテーブルのデフォルトのエンジンは CSV です。
テーブル データをファイルに設定する場合は、global log_output=file を設定します。
一般ログのログ ファイル パスを設定します。
グローバル general_log_file を '/tmp/general.log' に設定します。
一般ログを有効にする: global general_log=on を設定します。
一般ログを無効にする: global general_log=off を設定します。

次に、'general_log' のようなグローバル変数を表示します。

6. スロークエリログ

スロー ログには、実行に時間がかかり、インデックスを使用しないクエリ ステートメントが記録され、選択、更新、削除、および挿入ステートメントのエラーが報告されます。スロー ログには、正常に実行されたステートメントのみが記録されます。

1. 遅いクエリ時間を確認します。

「long_query_time」のような変数を表示します。デフォルトは 10 秒です。 

2. スロークエリの設定を確認します。

「%slow_queries%」のようなステータスを表示します。 

3. スロークエリログのパスを表示します。

「%slow%」のような変数を表示します。 

4. スローログを有効にする

有効になっているかどうかを確認します。

MySQL の 7 種類のログの概要についての記事はこれで終わりです。MySQL ログに関するより詳しい内容については、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続きご覧ください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。