目次
4. Mysql binlog にはいくつの入力形式がありますか? 違いは何ですか?
5. REDO ログはトランザクションの耐久性をどのように保証しますか?
6. ページが変更された後にディスクを更新するだけではどうでしょうか?
8. データベースを半月以内に任意の秒の状態に復元するにはどうすればよいですか?
9. REDO ログと binglog は、2 つのログ間の論理的一貫性をどのようにして確保しますか
10. UNDO ログはトランザクションのアトミック性をどのように保証しますか?
1. MySQL の一般的なログは何ですか?
-
REDO ログ: REDO ログはデータの復元に使用され、MySQL の異常なダウンタイム後にデータの整合性を確保するために使用されます。物理ログのみを記録します (ログは論理的な変更ではなく、データ ページの変更を記録します)。循環書き込みのため、 Rollを返す必要がないので上書きしても大丈夫です。
-
UNDO ログ: UNDO ログはトランザクションのロールバックに使用され、トランザクションのアトミック性、一貫性、分離性を保証できます。論理ログを記録し、循環的に書き込み、トランザクション操作の前に値を記録します。これは、トランザクションをロールバックするのに便利です。
-
binlog: バイナリ ログ。追加、削除、変更などの操作を含む、データベースを変更するすべての操作を記録し、データ回復やデータ レプリケーションなどのシナリオで使用されます。
-
エラー ログ: MySQL エンジンの実行中に発生するエラー、警告、その他の情報を記録するエラー ログ。トラブルシューティングに使用されます。
-
スロー クエリ ログ: 実行時間がしきい値を超えた SQL ステートメントを記録するスロー クエリ ログ。パフォーマンス チューニング、クエリの最適化、その他のシナリオで使用されます。
-
一般ログ: 一般ログ。クエリ、接続、切断、その他の操作を含むすべてのクライアント クエリとステータス変更情報が記録され、通常は問題診断とセキュリティ監査に使用されます。
-
リレー ログ: リレー ログ。MySQL マスター/スレーブ レプリケーションでのデータ送信に使用され、MySQL マスター ノードからスレーブ ノードにデータをコピーします。
2. スロークエリログは何に役立ちますか?
スロー クエリ ログは、実行時間がしきい値を超えた SQL ステートメントを記録するために MySQL で使用されるログで、通常はパフォーマンスの問題を分析するために使用されます。実行時間が指定したしきい値を超えた各 SQL ステートメントを記録し、実行時間、アクセスされたテーブル、使用されたインデックス、SQL を実行したユーザーなどの情報を記録できるため、開発者はクエリが遅い原因を特定し、解決策を最適化することができます。
低速クエリ ログは、開発者が実行に時間がかかる SQL ステートメントを特定して、対象を絞った最適化を実行できるようにするのに役立ちます。最適化方法には、クエリ ステートメントの記述の最適化、インデックスの追加、大きなテーブルの分離などが含まれますが、これらに限定されません。スロークエリのログを分析することで、開発者はシステムのボトルネックとパフォーマンスの問題をより深く理解し、より良い最適化戦略を策定できます。
スロークエリログは、MySQL 設定ファイルでパラメータを設定することslow_query_logによってlong_query_time。このうちslow_query_logパラメータはスロークエリログ機能を有効または無効にするために使用され、long_query_timeパラメータは実行時間が何秒を超えたSQL文をスロークエリログに記録するかを設定するために使用されます。
3. binlog は主に何を記録しますか?
binlog (バイナリログ) は、データベースの追加、削除、変更など、データに対するすべての変更操作を記録する MySQL のログ ファイルです。これは MySQL の重要な機能であり、データ レプリケーション、データ リカバリ、データ セキュリティの基礎です。
Binlog は主に次の種類の情報を記録します。
1. データベースの追加・削除・変更操作
Binlog は、テーブル構造への変更を含む、データベースへのすべての追加、削除、および変更を記録します。各書き込み操作で、MySQL は操作のデータをバイナリログに書き込みます。
2. トランザクションのコミットとロールバックの情報
トランザクションがコミットされると、MySQL はトランザクションのコミット情報を binlog に書き込みます。トランザクションがロールバックされると、MySQL はロールバック情報もバイナリログに書き込みます。この時点でバイナリログに記録された情報はデータのリカバリに使用できます。
3. データベースのステータス情報
binlog には、MySQL のバージョン、サーバーの ID、実行されたスレッドの ID など、MySQL のステータス情報が記録されます。
binlog の使用シナリオ:
-
データ レプリケーション: MySQL のマスター/スレーブ レプリケーションは、binlog を通じて実装されます。マスター ライブラリは変更操作を binlog に書き込み、スレーブ ライブラリはマスター ライブラリの binlog ファイルを読み取ることで複製します。
-
データ回復: データベースへのすべての変更はバイナリログに記録されるため、バイナリログはデータ回復に使用できます。
-
データのバックアップ: binlog ファイルをバックアップすると、必要に応じて特定の時点のデータ状態を復元できます。
バイナリログには、行レベルの変更ではなく、SQL ステートメントの変更操作が記録されることに注意してください。したがって、データをリストアする際に、ファイルを直接変更するなど、SQL 以外のステートメントを使用した変更方法がある場合、binlog を使用してリストアすることはできません。
4. Mysql binlog にはいくつの入力形式がありますか? 違いは何ですか?
MySQL のバイナリログには、ステートメント、行、混合の 3 つの形式があります。
- ステートメント形式: レコードは SQL ステートメントです。マスター ライブラリで実行された SQL ステートメントは binlog に記録され、SQL ステートメントはスレーブ ライブラリで再生されてマスター/スレーブ レプリケーションが実現されます。この形式は比較的単純で、データ量が少なく、書き込み操作が単純なシナリオに適しています。
- 行フォーマット: 行の変更を記録します。マスター ライブラリで実行された各行レベルの書き込み操作はバイナリログに記録され、対応する行がスレーブ ライブラリで変更されてマスター/スレーブ レプリケーションが実現されます。この形式は比較的複雑ですが、大量のデータや頻繁な書き込み操作を行うシナリオに適しています。
- 混合形式: ステートメントと行の 2 つの形式が混合されます。MySQL は、特定の操作に応じて使用する形式を選択します。この形式は、上記の 2 つの形式の利点を考慮に入れることができますが、実装はより複雑になります。
5. REDO ログはトランザクションの耐久性をどのように保証しますか?
MySQL では、REDO ログは主にトランザクションの永続性を確保するために使用され、その実装は次のとおりです。
トランザクションがコミットされると、InnoDB エンジンはまずトランザクションの REDO ログをメモリ内の REDO ログ バッファにキャッシュし、同時にメモリ内の対応するデータ ページを更新し、その後適切なタイミングで REDO ログを更新します。 REDO ログ バッファ内 ディスク上の REDO ログ ファイルに書き込み、クラッシュなどの異常な状況で REDO ログを通じてトランザクションを確実に回復できるようにします。
ディスクに書き込むとき、MySQL は REDO ログ ファイルを 2 つのファイルで構成される循環キューに書き込みます。各ファイルのサイズは構成パラメータによってinnodb_log_file_size制御されデフォルト値は 48MB です。書き込み時は最初のファイルから順に書き込みを開始し、いっぱいになると次のファイルに書き込みを続けます。
REDO ログはディスクに順次書き込まれるため、ディスクへの書き込み効率が向上します。同時に、REDO ログは循環キュー方式を採用しており、上書きを実現し、ディスク領域を節約できます。
InnoDB の REDO ログはサイズが固定されており、たとえば、それぞれのサイズが 1GB の 4 つのファイルのセットとして構成できます。
書き込み位置はカレントレコードの位置で、書き込み中は逆方向に進み、ファイル No.3 の最後まで書き込んだ後、ファイル 0 の先頭に戻ります。チェックポイントは消去する現在位置であり、逆方向および循環的に移動されます。レコードを消去する前に、レコードをデータ ファイルに更新する必要があります。
書き込み pos とチェックポイントの間には、まだ空の「ピンクのボード」の部分があり、新しい操作を記録するために使用できます。書き込み pos がチェックポイントに追いついた場合は、「ピンクのボード」がいっぱいで、現時点では新しい更新を実行できないことを意味します。最初にいくつかのレコードを停止して消去し、チェックポイントを進める必要があります。
REDO ログを使用すると、InnoDB はデータベースが異常に再起動した場合でも、以前に送信されたレコードが失われないことを保証できます。この機能はクラッシュ セーフと呼ばれます。
6. ページが変更された後にディスクを更新するだけではどうでしょうか?
データベースでは、データの変更とは、ディスク上のデータ ファイルを直接変更するのではなく、メモリ内のデータ ページを変更することを指します。この主な理由は、書き込みパフォーマンスを向上させ、データの一貫性を確保することです。
変更操作が行われるたびにディスクに直接書き込むと、書き込みパフォーマンスに重大な影響を与えます。また、ディスクへの書き込みが頻繁に行われると、ディスクの寿命が短くなる可能性があります。さらに、変更をディスクに直接書き込むと、オペレーティング システムやハードウェアのエラーや中断が発生した場合など、データの不整合が発生する可能性があります。
したがって、データベースは通常、「Write-Ahead Logging (WAL)」と呼ばれるテクノロジーを使用して、データの変更をログ ファイルに記録します。ディスクに書き込む前に、トランザクションの永続性とアトミック性を確保するために、変更操作が REDO ログに記録されます。トランザクションがコミットされた場合にのみ、REDO ログ内の変更操作がディスク上のデータ ファイルに同期されるため、データの一貫性と耐久性が保証されます。
システムがクラッシュまたは再起動した場合、REDO ログの再生を通じてデータ ファイルを回復できます。これは、データベースでは、トランザクションがコミットされると、REDO ログ内のデータが最初にディスク上のデータ ファイルに書き込まれ、次にトランザクション コミットの識別子が REDO ログに書き込まれるためです。したがって、データベースの起動時に、REDO ログ内の操作を再実行するだけで、データを最新の状態に復元できます。
7. binlog と redolog の違いは何ですか?
-
REDO ログ (REDO ログ) は、トランザクションの耐久性を確保するために InnoDB ストレージ エンジン自体によって実装されるログです。トランザクションの実行中に InnoDB テーブル内のデータが変更されると、InnoDB はまず変更操作を REDO ログに記録し、メモリ内のデータ ページを更新します。トランザクションがコミットされる前に、InnoDB はデータの永続性を確保するために REDO ログをディスクに書き込みます。REDO ログは循環的にディスクに書き込まれ、再利用できます。REDO ログのサイズは固定されており、パラメータ
innodb_log_file_sizeによって。 -
binlog (アーカイブ ログ) は、MySQL データベース サービス層によって実装されるログで、どのデータベースのどのテーブルに対してどのような操作が実行されたかなど、データベースのすべての更新操作を記録します。binlog は、マスター/スレーブ レプリケーションやデータベースの回復などのシナリオで使用されます。binlog のログ レコードは順番に書き込まれ、再利用されません。binlog のサイズは可変であり、パラメータ
max_binlog_sizeによって。
2 つのログの違いは次の 3 点です。
-
REDO ログは InnoDB エンジンに固有であり、binlog は MySQL サーバー層によって実装され、すべてのエンジンで使用できます。
-
REDO ログは、「特定のデータ ページにどのような変更が加えられたか」を記録する物理ログであり、binlog は、「行 ID= の c フィールドに 1 を追加する」など、このステートメントの元のロジックを記録する論理ログです。 2インチ。
-
REDO ログは周期的に書き込まれ、スペースは常に使い果たされるため、バイナリログを追加できます。「追記書き込み」とは、binlog ファイルが一定のサイズに書き込まれた後、次のファイルに切り替わり、前のログを上書きしないことを意味します。
8. データベースを半月以内に任意の秒の状態に復元するにはどうすればよいですか?
Binlog はすべての論理操作を記録し、「追記書き込み」の形式を採用します。DBA が半月以内に復元できると約束した場合、過去半月のすべてのバイナリログがバックアップ システムに保存され、システムはデータベース全体を定期的にバックアップします。ここでの「定期的」とは、システムの重要性に応じて、1 日に 1 回または週に 1 回にすることができます。
たとえば、ある日の午後 2 時に、指定した秒に復元する必要がある場合、正午 12 時にテーブルが誤って削除されたことに気づき、データを取得する必要があるとします。あなたはこれを行うことができます：
- まず、最新の完全バックアップを見つけます。運が良ければ、それは昨夜のバックアップである可能性があり、このバックアップから一時ライブラリに復元します。
- 次に、バックアップの時点から開始して、バックアップ バイナリログを順番に取り出し、正午にテーブルが誤って削除される直前まで再生します。
このようにして、一時データベースは誤って削除される前のオンライン データベースと同じになり、必要に応じて一時データベースからテーブル データを取り出してオンライン データベースに復元できます。
9. REDO ログと binglog は、2 つのログ間の論理的一貫性をどのようにして確保しますか
REDO ログと binlog の論理的一貫性は 2 フェーズ コミットによって保証されます。変更操作を実行するとき、MySQL はまずこれらの操作を REDO ログに記録し、次にこれらの操作をバイナリログに記録します。REDO ログと binlog の記録順序が異なるため、それらの間に論理的な不一致が発生する可能性があります。論理的な一貫性を確保するために、MySQL では 2 フェーズ コミット メカニズムが導入されています。
2 フェーズ コミットでは、MySQL はまず準備フェーズへの変更操作を REDO ログに記録しますが、この時点ではトランザクションはコミットされません。次に、MySQL はこれらの操作を binlog に記録し、トランザクションを準備状態としてマークします。最後に、コミット フェーズでは、MySQL はトランザクションを準備状態からコミット状態に変更し、同時に REDO ログ内の操作をディスクに送信します。これにより、REDO ログと binlog の間の論理的一貫性が保証されます。
2 フェーズ コミットでは、準備フェーズでエラーが発生した場合、MySQL はトランザクションをロールバックし、バイナリログ内の対応する操作をロールバックとしてマークすることに注意してください。この場合、REDO ログと binlog の間に論理的な矛盾はありません。
REDO ログと binlog の論理的一貫性は 2 フェーズ コミットによって保証されます。これは、MySQL が ACID の A (原子性) と C (一貫性) を実現するための鍵でもあります。
10. UNDO ログはトランザクションのアトミック性をどのように保証しますか?
Undo ログは、トランザクションのアトミック性とロールバック操作を実装するために InnoDB ストレージ エンジンによって使用されるメカニズムです。トランザクションが変更されると、InnoDB は最初に変更前のデータを UNDO ログに書き込み、次にデータを変更します。トランザクションがロールバックされた場合、UNDO ログ内の情報を使用して、データを変更前の状態に復元できます。トランザクションの原子性を実現するため。
具体的には、トランザクションが開始されると、InnoDB はトランザクションの Undo ログを開き、トランザクションによって行われたすべてのデータ変更が最初に Undo ログに書き込まれ、その後データが変更されます。トランザクションがコミットされると、すべてのデータ変更が一度に REDO ログに書き込まれ、その後トランザクションのコミット ステータスが REDO ログに書き込まれ、トランザクションが正常にコミットされたことを示します。
トランザクションの実行中にエラーが発生し、ロールバックが発生した場合、InnoDB は元に戻すログの情報を使用してデータを変更前の状態に復元します。トランザクションがロールバックされると、InnoDB はトランザクションのデータ変更操作を元に戻し、変更されたデータを変更前のデータに復元し、これらの操作を REDO ログに書き込み、トランザクションのロールバックが成功したことを示します。
元に戻すログは主に、トランザクションのアトミック性とロールバックを保証するために使用されます。トランザクションの実行が失敗した場合、アンドゥ ログの情報を使用してデータを変更前の状態に復元できるため、データの損傷や不整合が回避されます。