MySQL の binlog/redolog/undolog の違いは何ですか?

MySQL binlog/redolog/undolog の違いは何ですか?

InnoDB のロック メカニズムについて話したい場合、必然的に MySQL ログ システム、binlog、redo ログ、undo ログなどが関係することになります。悪い、急いで友達と共有してください。

ログは mysql データベースの重要な部分であり、データベースの操作中のさまざまなステータス情報を記録します。 mysql ログには主に、エラー ログ、クエリ ログ、スロー クエリ ログ、トランザクション ログ、バイナリ ログが含まれます。

開発者として注目する必要があるのは、バイナリ ログ (binlog) とトランザクション ログ (redo ログ および undo ログ## を含む) です。 #). この記事では、次にこれら 3 種類のログについて詳しく紹介します。

bin log

binlog は、データベースによって実行された書き込み操作 (クエリを除く) 情報を記録するために使用され、バイナリ形式でディスクに保存されます。 binlog は mysql の論理ログで、Server レイヤーによって記録されます。任意のストレージ エンジンを使用する mysql データベースは ## を記録します# binlogログ。

論理ログ: 記録されているのは SQL 文であることがわかります
物理ログ:
• mysql

  データは最終的にデータ ページに保存され、物理ログにデータ ページの変更が記録されます。

binlog

は追加によって書き込まれます。各 binlog ファイルは、max_binlog_size パラメータを通じて設定できます。サイズが指定された値に達すると、ログを保存するために新しいファイルが生成されます。 実際のアプリケーションでは、

binlog

にはマスター/スレーブ レプリケーションとデータ リカバリという 2 つの主な使用シナリオがあります。

マスター/スレーブ レプリケーション:
• Master

  側で binlog を開き、binlog を各 ## に送信します。 #スレーブ 側、スレーブ 側は binlog を再生して、マスターとスレーブのデータの一貫性を実現します。

  データ回復:
mysqlbinlog
• ツールを使用してデータを回復します。
  binlog フラッシュのタイミング

InnoDB

ストレージ エンジンの場合、トランザクションがコミットされたときにのみ記録されます

biglog 、この時点ではレコードはまだメモリ内にあるため、biglog がディスクにフラッシュされたのはいつですか? mysql

sync_binlog パラメータを通じて biglog のフラッシュ タイミングを制御します。値の範囲は 0 ～ N:

0: 必須の要件はありません。ディスクに書き込むタイミングはシステムが決定します;

• 1:
commit# のたびに#;

• N: binlog は、N 個のトランザクションごとにディスクに書き込まれる場合、

  #binlog
をディスクに書き込む必要があります。

• 上記のことからわかるように、

  sync_binlog
の最も安全な設定は

1

であり、これは MySQL 5.7.7 でもあります。 以降のバージョンのデフォルト値。ただし、より大きな値を設定するとデータベースのパフォーマンスが向上するため、実際の状況では、値を適切に増やし、ある程度の一貫性を犠牲にしてパフォーマンスを向上させることもできます。 binlog ログ形式

binlog

ログには、

STATMENT

、ROW、MIXED# という 3 つの形式があります。 ##。 MySQL 5.7.7 より前のデフォルト形式は STATEMENT

、

MySQL 5.7.7 以降のデフォルト値は ROW 。ログ形式は binlog-format で指定します。 STATMENT

:

SQL
• ステートメントに基づくレプリケーション (

  ステートメントベースのレプリケーション、SBR)、各ステートメントは次のようになります。変更 データの SQL ステートメントは binlog に記録されます。 ROW

  : 行ベースのレプリケーション (
行ベースのレプリケーション、RBR
• ) は、各 SQL ステートメントのコンテキスト情報を記録しません。どのデータが変更されたかを記録する必要があるだけです。

  MIXED

  :
STATMENT
• および

  ROW 、MBR) に基づく混合ベースのレプリケーション、一般的なコピーSTATEMENT モードを使用して binlog を保存します。STATEMENT モードでコピーできない操作の場合は、ROW モードを使用します。 binlog# を保存します。 ##redo ログredo ログが必要な理由

トランザクションの 4 つの主要な特徴は誰もが知っています。そのうちの 1 つは次のとおりです。具体的には、トランザクションが正常に送信される限り、データベースに加えられた変更は永続的に保存され、いかなる理由であっても元の状態に戻すことはできません。

では、

mysql

はどのようにして一貫性を確保するのでしょうか?

簡単な方法は、トランザクションがコミットされるたびに、ディスクへの変更に関係するすべてのデータ ページをフラッシュすることです。ただし、これを行うと、主に次の 2 つの側面に反映される重大なパフォーマンス上の問題が発生します。

• Innodb は ページ 単位でディスク操作を実行し、トランザクションで変更できるのは数ページのデータのみであるためです。現時点で完全なデータ ページをディスクにフラッシュするのはリソースの無駄です。

• #トランザクションには複数のデータ ページの変更が含まれる場合があり、これらのデータ ページは物理的に連続していません。ランダム IO 書き込みを使用するとパフォーマンスが低すぎます。

そこで、

mysql は redo ログ を設計しました。具体的には、トランザクションがデータ ページに加えた変更を記録するだけです。これにより、パフォーマンスの問題 (比較的ファイルが小さく、シーケンシャル IO) が完全に解決されます。

REDO ログの基本概念

REDO ログ には 2 つの部分が含まれます。1 つはメモリ内のログ バッファ (REDO ログ バッファ) , もう 1 つはディスク上のログ ファイル (redo logfile) です。

mysqlDML ステートメントが実行されるたびに、レコードは最初に redo ログ バッファに書き込まれ、その後、操作レコードは redo ログ ファイル に書き込まれます。最初にログを書き込んでからディスクに書き込むこのテクノロジーは、MySQL でよく言及されている
WAL (Write-Ahead Logging) テクノロジーです。

コンピュータ オペレーティング システムでは、ユーザー スペース (

ユーザー スペース ) のバッファ データは通常、ディスクに直接書き込むことができず、オペレーティング システムのカーネル スペース (kernel space) を経由する必要があります。 ) バッファ (OS バッファ)。

したがって、

redo logbufferwriting redo logfile は、実際には最初に OS Buffer に書き込み、次にシステム fsync() を通じて を呼び出します。 それを redo ログ ファイル にフラッシュします。プロセスは次のとおりです。

mysqlサポート 3 つのタイミングredo ログ バッファ を redo ログ ファイル に書き込む場合は、innodb_flush_log_at_trx_commit パラメーターを使用して構成できます。各パラメーター値の意味は次のとおりです:

REDO ログ記録形式

前述したように、

REDO ログは実際にデータ ページへの変更を記録します。全ての変更記録を保存する必要はないため、redoログは固定サイズかつ循環書き込み方式で実装されており、最後まで書き込むと先頭に戻ってログを書き込みます。ループ。以下に示すように:

同時に、innodb には、必要な

redo ログ があることが簡単にわかります。 データ ページ もフラッシュする必要があります。また、フラッシュする必要がある データ ページ もあります。redo ログ の主な意義は、データ ページ

の要件を軽減することです。洗い流されます**。

上の図の write pos は、redo log 現在のレコード の LSN (論理シーケンス番号) 位置を表します。チェックポイント は、データ ページ変更レコードがフラッシュされた後の redo log に対応する LSN

(論理シーケンス番号) の位置を示します。

write poscheck point 間の部分は、新しいレコードの記録に使用される redo ログ の空の部分です。check の間point および write pos は、ディスクに書き込まれるデータ ページの redo log 変更レコードです。 write pos が check point に追いつくと、まず check point

を前方に押し出し、その位置を空けてから、新しいログを記録します。

innodb を起動すると、前回正常終了、異常終了に関わらず、必ず回復操作が行われます。 redo ログ はデータ ページの物理的な変更を記録するため、回復速度は論理ログ (binlog

など) よりもはるかに高速です。

innodb を再起動すると、最初にディスク内のデータ ページの LSN がチェックされます。データ ページの LSN がログ LSN の よりも小さい場合、リカバリは checkpoint

から開始されます。

ダウンタイム前に checkpoint のディスク ブラッシング プロセスが進行中で、データ ページのディスク ブラッシングの進行状況がログ ページのディスク ブラッシングの進行状況を超える状況もあります。このとき、データが表示されます。ページに記録されている LSN は、ログの LSN

よりも大きいです。このとき、ログの進行状況を超えた部分は表示されません。なぜなら、これ自体は、行われたことをやり直す必要がないことを意味するからです。

REDO ログと binlog の違い

binlog と redo log# の違いからわかります。 ##: binlog ログはアーカイブにのみ使用され、binlog のみに依存する場合、クラッシュ セーフ機能はありません。

ただし、redo log だけは機能しません。redo log は InnoDB に固有であり、ログ内のレコードは書き込まれた後に上書きされるためです。ディスク。したがって、データベースが停止して再起動されたときにデータが失われないようにするには、binlog と redo log の両方を同時に記録する必要があります。

undo log

データベース トランザクションの 4 つの主要な特性の 1 つはアトミック性です。具体的には、アトミック性とは、データベースに対する一連の操作 (すべてが成功するかすべてが失敗するかのいずれか) を指します。成功。

実際、原子性の最下層は undo log によって実現されます。 undo ログは主にデータの論理的な変更を記録します。たとえば、INSERT ステートメントは、それぞれの DELETE の undo ログに対応します。 UPDATE ステートメントは、反対側の UPDATE の undo ログ に対応するため、エラーが発生したときにトランザクション前のデータ状態にロールバックできます。

同時に、アンドゥ ログは、MVCC (マルチバージョン同時実行制御) 実装の鍵でもあります。

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