序文
MySQLと接触しているのがプログラマーである限り、多かれ少なかれ、やり直しログ（やり直しログ）とbinlog（アーカイブログ）について聞いたことがあるでしょう。今日は、これら2つのログの有用性と違いを共有します。
簡単に言うと、REDOログはInnoDBに固有のログです。他のストレージエンジンを使用している場合、REDOログはなく、binlogのみです。
BinlogはMySQLのサーバーログです。使用するストレージエンジンに関係なく、binlogがあります。では、なぜREDOログとBINログが必要なのですか？1つのbinlogですべてを解決することはできませんか？次に、REDOログとbinlogの違いを詳しく見ていきましょう。
ログをやり直す
REDOログはREDOログと呼ばれ、トランザクションの変更を記録するために使用され、データが変更された後の値を記録します。InnoDBは、REDOログを使用して、トランザクション更新の一貫性と耐久性を確保します。
MySQLでは、ステートメントを更新する場合は、次のような更新条件を用意する必要があります。Tセット名= 'god-jiang'を更新します。ここでid = 6、通常、id = 6のセンテンスが最初に照会され、次に更新操作が実行されます。
更新の数が100、1,000、さらには10,000の場合、すべての更新をディスクに書き込む必要があります。次に、ディスクは対応するレコードを見つけて更新する必要があります。プロセス全体のIOコストと検索コストが大きすぎます。この問題を解決するために、MySQLの設計者はWALテクノロジを採用して解決しました。WALのフルネームはログ先行書き込み、これは、最初にログを書き込み、次にディスクに書き込むことを意味します。
特定の操作：レコードを更新する必要がある場合、InnoDBエンジンは最初にレコードをREDOログに書き込み、メモリを更新します。この時点で、更新は完了です。同時に、InnoDBエンジンは、適切なタイミング（システムがアイドル状態のとき）にこの操作レコードをディスクに更新します。この更新は、多くの場合、システムが比較的アイドル状態のときに行われます。
ただし、REDOログのサイズは固定されており、無制限に書き込むことはできません。MySQLでそれを実行する方法を見てみましょう。
MySQLは、書き込み位置とチェックポイントをサイクリック書き込みで使用して、データを時間内にディスクに更新できるようにします。
write posは現在のレコードの位置であり、書き込み中に後方に移動します。チェックポイントは、消去する現在の位置であり、後方に移動してループします。レコードを消去する前に、レコードをデータファイルに更新する必要があります。
いつib_logfile_3いっぱいになったら帰りますib_logfile_0書き続ける。そしてib_logfile_xすべてのグループはMySQLを介して構成できますが、構成されたREDOログのサイズは固定されています。
書き込み位置とチェックポイントの間の部分は、新しい操作を記録できることを示しています。書き込み位置がチェックポイントに追いついた場合は、REDOログがいっぱいであることを意味します。この時点では、新しい操作を続行できません。一部のレコードを消去してチェックポイントを進めるには、停止する必要があります。
InnoDBは、REDOログを使用して、データベースが異常に再起動された場合でも、以前にコミットされたトランザクションが失われないことを保証できます。この機能は、クラッシュセーフ。
上記はREDOログの紹介です。それを読んだ後、MySQLを半月以内に任意の秒の状態に復元できるかどうかを会社のDBAの同僚に尋ねることができます。答えは間違いなくイエスです。REDOログのクレジット。
binlog
binlogは、すべてのDDL（データ定義ステートメント）とDML（データ操作ステートメント）を記録しますが、selectとshowは含まれません。
Binlogは、主にPOINT-IN-TIME（PIT）リカバリおよびマスタースレーブレプリケーション環境の確立に使用されます。表面的には、データベース操作のログを記録するREDOログに非常に似ていますが、本質的には、依然として非常に大きな違いがあります。
やり直しログとbinlogの違い
- まず、REDOログはInnoDBストレージエンジンレイヤーで生成され、binlogはデータベースの上位レイヤーで生成されます。binlogはInnoDBストレージエンジンだけでなく、MySQLデータベース内のすべてのストレージエンジンがbinlogを生成します。
- 次に、2つのログの内容が異なる方法で記録されます。Binlogは、対応するSQLステートメントを記録する一種の論理ログであり、REDOログは、各ページの変更に対応する一種の物理ログです。
- 最後に、2つのログは異なる時点でディスクに書き込まれます。Binlogはトランザクションがコミットされた後に1回だけ書き込みますが、REDOログはトランザクション中に継続的に書き込みます。これはトランザクション送信の順序では書き込まれません。
- Binlogは通常、データリカバリに使用され、マスタースレーブレプリケーションが構築されます。REDOログは通常、MySQLの異常なダウンタイムまたはメディア障害後のデータリカバリに使用されます。
簡単な更新ステートメントを使用して、エグゼキュータとInnoDBエンジンの内部フローを示します
update T set name = 'god-jiang' where id = 6
- id = 6のレコードは、エグゼキュータを介してInnoDBエンジンから取得され、メモリにロードされます。
- エグゼキュータは、エンジンから返された結果を取得し、名前を「god-jiang」に変更してから、ストレージエンジンのインターフェイスを再度呼び出して、新しいデータを書き込みます。
- エンジンは新しいデータをメモリに更新すると同時に、更新操作をREDOログに書き込みます。このとき、REDOログは準備状態です。
- エグゼキュータはこの操作のbinlogを生成し、binlogをディスクに書き込みます
- エグゼキュータはエンジンのインターフェースを呼び出してトランザクションを送信し、コミット状態に書き込まれたばかりのREDOログを変更し、更新が完了します。
対応するフローチャート
最後に、準備状態でREDOログへの書き込みを行っても、binlogへの書き込みがコミット状態になるのはなぜですか？実際、このプロセスは「2フェーズコミット」と呼ばれます。
2フェーズコミット
実際、REDOログとbinlogの両方を使用して、トランザクションコミットのステータスを示すことができます。2フェーズコミットは、これら2つの状態を論理的に一貫性のある状態に保つことです。
例えば：Tセット名= 'god-jiang'を更新します。ここでid = 62フェーズコミットがないとどうなりますか？
最初にREDOログを書き込み、次にbinlogを書き込みます。REDOログが書き込まれ、binlogがまだ書き込まれていないと仮定すると、この時点でMySQLは異常に再起動します。REDOログが書き込まれているため、システムを復元するときはname = 'god-jiang'です。ただし、binlogは終了していないため、binlogはこのステートメントを記録しません。このとき、binlogを使用してデータを復元する場合、復元される名前は元の値であり、REDOログとは異なります。
同様に、最初にbinlogを書き込んでから、REDOログを書き込むと、2つのログによって復元されたデータが異なることがわかります。この不整合は、回線上のマスタースレーブの不整合につながります。
総括する
- REDOログはクラッシュセーフ機能を保存でき、MySQLが異常に再起動したときにデータが失われないようにすることができます
- binlogは、対応するSQLステートメントを記録でき、MySQLが異常に再起動したときにデータが失われないようにすることもできます。
- コミットトランザクションの2フェーズコミットは、データの論理的な一貫性を維持できます
参照
- 「MySQLの実際の戦闘に関する45の講義」LinXiaobin
- 「高性能MySQL」第3版1.3トランザクション
- 「MySQLTechnicalInsider」の第2版7.2トランザクションの実装