mysqlのREDOログとbinlogの違いは何ですか

mysql の 2 つの小さな知識ポイント、redo ログと binlog について話したいと思います。

redo ログ: InnoDB ストレージ エンジン層のログなので、使用するストレージ エンジンが InnoDB ではない場合、REDO ログはまったくありません。

binlog: MySQL Server レイヤーによって記録されるログなので、どのストレージ エンジンが使用されていても、MySQL である限り、binlog が存在します。スレーブ レプリケーションでは、binlog が使用されます。

次に、彼らが何をするのか詳しく見てみましょう。

redo ログ

なぜこの REDO ログ ファイルが必要なのでしょうか?

ここで、例を示します。次に、データベース内のデータを変更します。次に、更新ステートメントが来ます。一般に、更新操作にはクエリ操作が伴います。最初に検索する必要があります。このデータを指定して、更新操作を実行しますよね。

データの量が比較的少ない場合は、すぐに見つけて更新できるので問題ありませんが、データの量が比較的多く、1 億個のデータが含まれている場合はどうなるでしょうか?さらに、更新操作はディスクに書き込む必要があるため、中間の IO コストはいくらになるでしょうか?

数十の更新ステートメントが次々に更新される場合はどうなりますか?このように考えると、これらの作業にかかるコストは非常に高額であることが想像できますが、このコストを削減することはできるのでしょうか?

このとき、REDO ログが活躍します。レコードが更新されると、InnoDB エンジンはまずレコードを REDO ログに書き込み、同時にメモリを更新して、データが正常に更新されるようにします。

でも、この時点ではディスクには更新されていませんよね？心配しないでください。InnoDB は適切なタイミングでこのレコードをディスクに更新します。

この種の考え方またはテクノロジには、適切な名前があります: WAL テクノロジ、これは WriteAheadLogging です。中心となるのは、最初にログを書き込み、次にディスクに書き込むことです。

redo ログを書き続けることができませんか?

REDO ログのサイズは固定されており、以前の内容は上書きされます。容量がいっぱいになると、後続の変更を記録するためのスペースを確保するために、ディスクへの REDO ログの同期が開始されます。 。

データベースが停止または再起動しても、データは失われません。

REDO ログがあるため、以前に送信されたレコードはまだ存在します。必要なのは、REDO ログ内のレコードに基づいてそれらを復元することだけです。

binlog

Binlog は、MySQL Server 層の記録ログです。

REDO ログと binlog の違い:

• REDO ログは InnoDB エンジンに固有であり、binlog は MySQL のサーバー層によって実装され、すべてのエンジンで利用できます。 。

• redo ログは、「XXX ページで XXX の変更が行われました」を記録する物理ログです。binlog は、「次の行の c フィールドに 1 を追加します」などの論理ログです。 id = 2””。

• REDO ログのサイズは固定されているため、そのスペースが使い果たされます。使い果たされた場合は、続行する前にディスクに書き込むための操作をいくつか実行する必要があります。 binlog は追加可能 書き込み、つまり binlog にはスペースの概念がなく、ただ書き続けるだけです。

binlog は、すべての DDL および DML ステートメントをイベントの形式で記録し (データ値ではなく操作を記録するため、論理ログです)、 メインとして使用できます。レプリケーションとデータリカバリから。

binlog 機能がオンになっている場合、binlog を SQL ステートメントにエクスポートし、すべての操作を再実行してデータを回復できます。

これら 2 つのログを取得した後、更新ステートメントがどのように実行されるかを見てみましょう (REDO は一度に書き込むことはできません):

例: ステートメント: update user set name='Xiao Ma' where id=1;

• キャッシュがある場合は、最初にこのデータをクエリします。 、キャッシュも使用されます。

• 名前を 小马に変更し、エンジンの API インターフェイスを呼び出し、このデータ行をメモリに書き込み、同時に REDO ログを記録します。 。この時点で、REDO ログは準備状態に入り、実行が完了し、いつでも送信できることを実行者に伝えます。

• 通知を受信した後、実行プログラムはバイナリログを記録し、ストレージエンジンインターフェイスを呼び出してREDOログをコミット状態に設定します。

• #アップデートが完了しました。

REDO ログは最初は準備状態にあり、バイナリログが書き込まれた後はコミット状態にあることがわかります。この方法は「2-ステージコミット」。なぜこのようになっているのでしょうか？

2 フェーズ コミットは、2 つの状態の論理的な一貫性を維持することを目的としています。

この方法を使用せずに、最初に REDO ログを書き込み、次に binlog を書き込んだ場合、何が起こると仮定できますか? binlog の書き込み時に例外が発生し、REDO ログで更新操作が実行されたが、この時点で binlog が更新されていない場合、データの不整合はありますか?

最初に binlog を書き込み、次に REDO ログを書き込む場合も同様です。そのため、書き込み時にはREDOログをPrepare状態にして、binlogの書き込み終了後にREDOログをCommit状態にすることで論理的な整合性を保ちます。

以上がmysqlのREDOログとbinlogの違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。