インタビュアー: MySQL の 2 フェーズの送信メカニズムについて話しましょう。

この記事では、MySQL の 2 フェーズ送信メカニズムを理解し、REDO ログと bin ログを紹介し、2 フェーズ送信を完了するためにそれらがどのように連携するかを説明します。

MySQL は、2 段階の送信メカニズムを通じて REDO ログと bin ログの論理的一貫性を確保し、それによってデータが失われず、マスター/スレーブ データベース内のデータが確実に失われることを保証します。一貫しています。

2 フェーズ送信について言えば、まず REDO ログと bin ログを導入する必要があります。

redo ログ

redo ログは、InnoDB エンジンに固有のログである REDO ログです (これについてよく質問する面接官もいます)。

REDO ログは主に何をするのですか?

データの更新を例にとります。MySQL データはディスクに保存されていることがわかっています。データが更新されるたびに、データはディスクに移動して更新対象のデータを検索し、更新操作を実行します。 IO コストは非常に高くなります。

ソリッド ステート ドライブであれば問題ありませんが、機械式ハード ドライブの場合、MySQL の更新パフォーマンスはビジネス ニーズを満たすことができません。

つまり、MySQL は WAL (Write-Ahead Logging) と呼ばれるテクノロジーを使用しています。

データを更新する場合、更新操作（つまり、特定のデータページにどのような変更が加えられたか）が最初にREDOログに書き込まれ、その後メモリが更新され、この更新操作が完了します。 MySQL は、データの一貫性を維持するために、サーバーがアイドル状態のときに REDO ログ操作レコードをディスクにフラッシュします。

REDO ログもディスク上のファイルですが、操作はシーケンシャルに書き込まれるため、パフォーマンスは非常に高いことに注意してください。

もちろん、REDOログにもサイズ制限があり、無制限に書き込むことはできません。

上図は例です。REDO ログが 4 つ設定されています。Write pos は現在のレコードが書き込まれる場所を表し、チェックポイントは As を表します。先に進むと、REDO ログの書き込みを継続できるように、引き続き前進してデータを消去します。

もちろん、データを消去する前に、REDO ログ レコードがディスクにフラッシュされます。

REDO ログを使用すると、MySQL が異常に再起動してもデータが失われないことを保証できます (REDO ログは物理ログであり、再生できるため)。この機能はクラッシュ セーフと呼ばれます。

bin ログ

bin ログは、アーカイブ ログと呼ばれる、MySQL Server によって提供されるログです。すべてのエンジンで bin ログを使用できます。

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

1. これら 2 つのログのプロバイダーは異なります: bin ログは MySQL Server によって提供され、REDO ログは InnoDB エンジンに固有です。

2. REDO ログは主に特定のデータ ページに加えられた変更を記録し、bin ログは特定の行の特定のフィールドの更新など、ステートメントの元のロジックを記録します。

3, REDO ログはループで書き込まれ、データは上書きされます。 Bin ログが追加され、1 つのファイルがいっぱいになると、次のファイルが書き込まれます。

2 フェーズ送信

REDO ログと bin ログを紹介した後、これらがどのように連携して 2 フェーズ送信を完了するかを見てみましょう。

#上の図はデータ更新のプロセスです。データを更新する前に、MySQL がまずデータをメモリを更新し、REDO ログの書き込みを開始します。

現時点では、REDO ログは準備状態にあり、bin ログが書き込まれ、トランザクションが送信されると、このレコードの更新操作が完了します。

REDO ログの準備 -> bin ログの書き込み -> REDO ログのコミット、このプロセスは 2 段階コミットと呼ばれます。

2 段階の送信を使用する利点を分析してみましょう。

シナリオ 1: REDO ログが準備状態にあるときに、bin ログへの書き込みが失敗すると、更新は失敗します。この時点では、REDO ログにはコミットがなく、bin ログにはレコードがありません。両者の状態は一致しており問題ありません。

シナリオ 2: REDO ログが準備状態にある場合、bin ログは正常に書き込まれますが、ダウンタイムによりコミットが失敗します。このとき、bin ログにレコードが生成され、REDO ログが正常に書き込まれず、データが一時的に不整合になりました。

ただし、心配しないでください。MySQL が再起動すると、REDO ログ内の準備状態のレコードがチェックされます。 REDO ログには、「実際には、書き込みが成功しなかった場合、送信は諦められます。」というフィールドがあります。

このメカニズムにより、REDO ログと bin ログの一貫性が保証されます。

概要

MySQL に REDO ログと bin ログの両方が存在する理由は、bin ログは MySQL Server によって提供されるアーカイブ ログであり、それ自体にクラッシュセーフ機能がないためです。能力。 REDO ログ自体にはアーカイブ機能はなく、ループで書き込まれるログです。

MySQL は、これら 2 つのログを統合し、2 段階の送信メカニズムを使用することで、データの一貫性を保証します。

書くのは簡単ではありません。「いいね！」と注目していただきありがとうございます。

[関連する推奨事項: mysql ビデオ チュートリアル ]

以上がインタビュアー: MySQL の 2 フェーズの送信メカニズムについて話しましょう。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。