MySQL データベース面接に必須の 3 つのログの紹介

では、まず次の質問について考えてみましょう。MySQL はどのようにしてデータが失われないようにするのでしょうか?

実際、データが失われないようにするには、次の 2 つの機能が必要です。
（１）いつでも元の状態に復元できること
（２）MySQLが突然クラッシュして再起動した場合でも、送信されたデータが失われず、不完全なデータが自動的にロールバックされることを保証できます。

これは、今日お話しするトピックに関係しているのではないでしょうか。最初のポイントを達成するには、bin ログを使用する必要があり、2 番目のポイントを達成するには、redo ログと undo ログを使用する必要があります。

3 つの主要なログを理解する前に、Mysql データ更新のプロセスを見てみましょう。

上の図は、REDO ログ、BIN ログ、UNDO ログの 3 種類のログ間の一般的な関係を示しています。それでは、本題に入りましょう。

1. redo ログ (MySQL ストレージ エンジン InnoDB のトランザクション ログ)

MySQL データはディスクに保存され、データの読み取りまたは書き込みのたびにディスク IO が必要になるため、同時実行シナリオではパフォーマンスが低下することがわかっています。この目的のために、MySQL では最適化のためのキャッシュバッファ プールが導入されています。データベースのディスク負荷を軽減するために、ディスク上のいくつかのデータ ページのマッピングが含まれています。

データベースからデータを読み取るときは、まずキャッシュから読み取られます。データがキャッシュにない場合は、ディスクから読み取られてキャッシュに格納されます。データベースにデータを書き込むときは、まずキャッシュに書き込まれます。このとき、キャッシュ内のデータ ページのデータが変更されます。このデータ ページはダーティ ページと呼ばれます。バッファー プール内のデータが変更されると、設定された戦略に従って定期的にディスクにフラッシュされます。このプロセスは、ダーティ ページのフラッシュと呼ばれます。

質問は、バッファ プール内の変更されたデータが時間内にディスクにフラッシュされない場合、MySQL がクラッシュして再起動し、データが失われ、トランザクションの永続性が保証されなくなるということです。どうすればよいでしょうか?

REDO ログはこの問題を解決します。つまり、データベースがデータを変更すると、まず更新レコードが REDO ログに書き込まれ、次にバッファー プール内のデータが変更されます。トランザクションがコミットされると、fsync が呼び出され、REDO ログがディスクにフラッシュされます。キャッシュ内の更新されたデータ ファイルがディスクにフラッシュされるタイミングについては、バックグラウンド スレッドによって非同期的に処理されます。

注意: この時点では、REDO ログ トランザクション ステータスは準備中であり、実際には正常にコミットされていません。バイナリ ログがディスクに書き込まれるまで、コミットに変わりません。その後でのみ、トランザクションは実際に正常にコミットされます。

REDOログを書き込むにはどうすればいいですか?

REDO ログは固定サイズで循環的に書き込まれます。いっぱいになると、リングと同様に最初から循環的に再度書き込まれます。この設計の理由は、REDO ログがデータ ページの変更を記録するためです。バッファー プールのデータ ページがディスクにフラッシュされると、これらのレコードは無効になり、新しいログによってこれらの無効なレコードが上書きされ、消去されます。

注意: REDO ログがいっぱいの場合は、消去する前に、消去するすべてのレコードがディスクにフラッシュされていることを確認してください。新しいスペースを解放するために古いレコードを消去している間は、新しい更新要求を受信できず、MySQL のパフォーマンスが低下します。したがって、同時実行性が高い状況では、REDO ログ サイズを適切に調整することが重要です。

クラッシュセーフ機能とは何ですか?

Innodb エンジンにはクラッシュセーフ機能があり、トランザクション送信プロセスのどの段階でも、MySQL がクラッシュして再起動した後でもトランザクションの整合性が保証され、送信されたデータが失われることはありません。この機能は、REDO ログによって保証されます。MySQL がクラッシュして再起動すると、システムは自動的に REDO ログをチェックし、まだディスクに書き込まれていない変更されたデータを REDO ログから MySQL に復元します。

2. UNDOログロールバックログ（MySQLストレージエンジンInnoDBのトランザクションログ）

UNDO ログは、データが変更される前の状態を記録します。論理ログに属し、ロールバックの役割を果たします。トランザクションのアトミック性を保証する鍵となります。
たとえば、ID=1 のレコードの名前フィールドが更新されると、元の名前データは Xiao Wang ですが、名前が Xiao Zhang に変更されます。トランザクションが update X set name = Xiao Zhang where id = 1 ステートメントを実行すると、反対のロジックを持つ update X set name = Xiao Wang where id = 1 レコードが最初に undo ログに記録されます。このように、何らかの理由でトランザクションが失敗した場合、undo ログを使用して、トランザクションが実行される前の状態にデータをロールバックできます。

そこで疑問になるのが、同じトランザクションのレコードが複数回変更された場合、そのたびにデータ変更前の状態の UNDO ログを書き込む必要があるかどうかです。

いいえ。UNDO ログには、トランザクションが開始される前の元のデータのみが記録されるためです。このデータ行が再度変更されると、生成された変更レコードが REDO ログに書き込まれます。 UNDO ログはロールバックを担当し、REDO ログはロールフォワードを担当します。

ロールバックとロールフォワードとは何ですか?

（１）ロールバック

コミットされていないトランザクション、つまり、コミットされていないトランザクション。ただし、トランザクション内で変更されたダーティ ページの一部はディスクにフラッシュされています。このとき、データベースがクラッシュして再起動し、ディスクからフラッシュされたダーティ ブロックを削除するにはロールバックが必要になります。

（２）前転

不完全にコミットされたトランザクションとは、トランザクションはコミットされたものの、トランザクションで変更されたダーティ ページのデータの一部のみがディスクにフラッシュされ、残りの部分はバッファー プールに残っていることを意味します。このとき、データベースがクラッシュして再起動すると、ロールフォワードを使用して、ディスクにフラッシュされていないデータを REDO ログから回復し、ディスクにフラッシュします。

3. バイナリログアーカイブログ（エンジンに関係なく、データベースサーバー層のバイナリ論理ログ）

bin ログには、データベース上でユーザーが実行したすべての SQL 操作が記録されます (クエリ ステートメントは除きます。このような操作ではデータ自体が変更されないためです)。アーカイブログと呼ばれる理由は、REDOログのように過去の記録を周期的に消去するのではなく、ログを記録し続けるからです。 bin ログ ファイルのデフォルトの最大容量は 1G です (max_binlog_size パラメータで変更できます)。 1 つのログが最大値を超えると、書き込みを続行するために新しいファイルが作成されます。
注: ログはトランザクションに基づいて記録されますが、トランザクションは複数のファイルに記録されません。binlog ログ ファイルが最大値に達してもトランザクションがコミットされていない場合、新しいファイル レコードは作成されませんが、ログは大きくなり続けます。したがって、max_binlog_size の値は必ずしも実際の binlog ファイル サイズと同じではありません。

上記の紹介の後、binlog は主にマスターとスレーブの同期と、時点に基づくデータベースの復元に使用されます。

そこで疑問になるのが、binlog なしでも実行できるかどうかです (REDO ログがあるのに、なぜ bin log が必要なのでしょうか)。

シーンを見る必要があります:

マスタースレーブモードでは、スレーブデータベースのデータ同期は binlog に依存するため、binlog が必要です。

スタンドアロン モードでは、データベースのポイントインタイム復元を考慮しない場合、REDO ログによってクラッシュセーフ機能が保証されるため、binlog は必要ありません。

REDO ログ レコードが変更されてディスクに書き込まれると、ログは上書きされ、データ回復などの操作に使用できなくなります。REDO ログは InnoDB エンジン レイヤーで実装されており、すべてのエンジンに実装されているわけではありません。

REDO ログと bin ログの違いは何ですか?

REDO ログ 2 フェーズ コミットとは何ですか? また、なぜそれを実行するのですか?
メモリが更新されると、エンジン層はREDOログを書き込み、ステータスを最初のステージのコミット準備に変更します。サーバー層はBINログを書き込み、ステータスをコミットに変更して、2番目のステージをコミットします。 2 フェーズ コミットの目的は、binlog と redo ログ データの一貫性を確保することです。

2 フェーズコミットでなかったらどうなるでしょうか?
1) 最初に redo ログが書き込まれ、次に bin ログが書き込まれると仮定します。つまり、redo ログには準備段階がありません。書き込み後、直接コミットに設定され、その後 bin ログが書き込まれます。 REDO ログの書き込み後、BIN ログの書き込み前にデータベースがクラッシュした場合、システムは再起動後に REDO ログを使用して自動的に回復します。このとき、ディスク上のデータ ページ データは BIN ログに記録されたデータよりも多くなり、データの不整合が発生します。
2) 最初に bin ログが書き込まれ、次に redo ログが書き込まれると仮定します。bin ログが書き込まれた後に redo ログが書き込まれずにデータベースがクラッシュした場合、bin ログのレコードはディスク上のデータ ページのレコードより多くなります。次に bin ログを使用してデータを復元すると、復元されたデータは元のデータと一致しなくなります。

REDO ログ災害復旧プロセスについて説明してください。
REDO ログが完了している (コミットされている) 場合は、REDO ログを使用して直接復元します。
再実行ログが準備状態にあるがコミット状態ではない場合は、バイナリログが完了しているかどうかを確認する必要があります。完了している (コミットされている) 場合は、再実行ログをコミットし、その再実行ログを使用して回復します。不完全な場合は、トランザクションをロールバックします。

MySQLデータベース面接に必須の3つのログについての記事はこれで終わりです。MySQLの主要3ログについての詳細は、123WORDPRESS.COMの過去の記事を検索するか、以下の関連記事を引き続きご覧ください。今後とも123WORDPRESS.COMをよろしくお願いいたします。