MySQL の Redo ログ、Undo ログ、bin ログ

最近は、MySQL の高度な部分に関する知識を復習しています — Mr. Song Hongkang の MySQL チュートリアル

1.やり直しログ

InnoDB ストレージ エンジンは、ストレージ スペースの管理に页为单位使用されます。実際にページにアクセスする前に、磁盘上ページをメモリにキャッシュする必要がありますバッファプールその後のみアクセス可能。すべての変更は最初にバッファー プールを更新するバッファプール内のデータ、次に汚いページ特定の頻度でディスク (checkPointメカニズム)にフラッシュされ、全体的なパフォーマンスが急速に低下しないように、CPU とディスクの間のギャップがバッファー プールによって最適化されます。

1.1 REDO ログが必要な理由

一方では、バッファー プールは、CPU とディスクの間のギャップを埋めるのに役立ちます。チェックポイントこのメカニズムは、データの最終的な配置を保証できますが、変更があるたびにチェックポイントがトリガーされるわけではありませんはい。ただし、マスター スレッドは時々それを処理します。したがって、最悪のケースはトランザクションがコミットされた後、バッファー プールが書き込まれたばかりで、データベースがダウンしている場合、このデータは失われ、回復できません。

一方、トランザクションには特性が持久性含まれています。つまり、コミットされたトランザクションの場合、トランザクションがコミットされた後にシステムがクラッシュしても、トランザクションによってデータベースに加えられた変更は失われません。

では、この永続性を確保するにはどうすればよいでしょうか。一个简单的做法: トランザクションのコミットが完了する前に、トランザクションによって変更されたすべてのページをディスクにフラッシュしますが、この単純で粗野なアプローチにはいくつかの問題があります。

• 基本単位が 16 バイトのデータ ページであることを考えると、変更の量は、ディスクを更新する作業負荷に対して非常に不釣り合いです。

  ページ内の 1 バイトのみを変更することもありますが、InnoDB ではディスク IO がページ単位で実行されること、つまり、トランザクションがコミットされるときにメモリからページ全体を削除する必要があることもわかっています。デフォルトのページ サイズは 16KB であり、1 バイトを変更するだけで 16KB のデータをディスクに更新するのは明らかにやり過ぎです。

• ランダム IO の更新が遅い- トランザクションの変更ステートメントに多くのページが含まれている可能性があり、ランダム IO に時間がかかりすぎる

  トランザクションには多くのステートメントが含まれる場合があり、1 つのステートメントで多くのページが変更される場合もあります。トランザクションによって変更されたページが隣接していない可能性がある場合、これは、トランザクションがバッファー プール内のページを変更するときに、 Many 、ランダム IO が必要であることを意味し刷新到磁盘ます随机IO。特に従来の機械式ハードドライブの場合、シーケンシャル IO よりも遅くなります。

另一个解决的思路：再起動後、失われた変更を復元し、変更されたものを記録するだけです. たとえば、トランザクションは、システム テーブルスペースのページ 10 のオフセット 100 にあるバイトの値 1 を 2 に変更します。記録する必要があるだけです。テーブルスペース 0 のページ 10 のオフセット 100 の値を 2 に更新します。

InnoDBエンジンのトランザクションはWAL技術を採用(先行書き込みロギング）、このテクニックのアイデアは最初にログに書き込み、次にディスクに書き込みます、ログが正常に書き込まれた場合にのみ、トランザクションは成功したと見なされ、ここでのログは REDO ログです。ダウンタイムが発生し、データがディスクにフラッシュされない場合、ACID の D を確保するために、REDO ログを介してデータを回復できます. これが REDO ログの役割です.

1.2 REDO ログの利点と特徴

1. メリット

• REDO ログはフラッシュの頻度を減らします

• REDO ログはほとんどスペースを占有しません

  テーブルスペース ID、ページ番号、オフセット、および更新が必要な値を格納するために必要なストレージ領域は非常に小さく、ディスクはすぐに更新されます。

2.特徴

• REDO ログは順次ディスクに書き込まれます

  トランザクションの実行中に、ステートメントが実行されるたびに、いくつかの REDO ログが生成される場合があります、これらのログは に基づいています产生的顺序写入磁盘的。つまり、連続した ID を使用しており、効率はランダム IO よりも高速です。

• トランザクションの実行中、REDO ログは記録を続けます

  redo ログと bin ログの違いは、存储引擎层bin ログが数据库层生成されるときに redo ログが生成されることです。トランザクションが 100,000 行のレコードをテーブルに挿入すると仮定します. このプロセスの間、REDO ログに連続して記録されますが、bin ログには記録されません. トランザクションがコミットされるまで、bin ログ ファイルには書き込まれません. . .

1.3 REDOの構成

REDO ログは、単純に次の 2 つの部分に分けることができます。

• 重做日志的缓冲 (redo log buffer)、メモリに格納され、揮発性です。

  サーバーが起動すると、オペレーティング システムに redo log buffer と呼ばれる大きな连续内存領域。これは中国語に redo log buffer として翻訳されます。このメモリ空間は、いくつかの連続したものに分割されますredo log block。REDO ログ ブロックが512字节サイズを占有します (セクター サイズは 512 バイトです)。

パラメータ設定: innodb_log_buffer_size:

REDO ログ バッファ サイズ、デフォルト16M、最大値は 4096M、最小値は 1M です。

mysql> show variables like '%innodb_log_buffer_size%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+

• 重做日志文件 (redo log file) ハードディスクに保存され、永続的です。

  REDO ログ ファイルはデータ ファイル ディレクトリに保存されます。ここで、ib_logfile0と はib_logfile1REDO ログです。

1.4 REDO の全体的なプロセス

更新トランザクションを例にとると、REDO ログ フロー プロセスを次の図に示します。

• 最初のステップ: 元のデータをディスクからメモリに読み込み、データのメモリ コピーを変更します。
• ステップ 2: REDO ログを生成し、データの変更された値を記録する REDO ログ バッファに書き込みます。
• ステップ 3:トランザクションがコミットされたら、REDO ログ バッファの内容を REDO ログ ファイルに更新し、REDO ログ ファイルに追加で書き込みます。
• ステップ 4: メモリ内の変更されたデータをディスクに定期的に更新します。

エクスペリエンス: 先行書き込みログ (ログ前の永続性):データ ページを永続化する前に、まず対応するログ ページをメモリに永続化します。

1.5 REDO ログのフラッシュ戦略

Redo ログの書き込みはディスクに直接書き込まれるのではなく、InnoDB エンジンが Redo ログを書き込みます。最初に REDO ログ バッファを書き込んでから、一定的频率実際の REDO ログ ファイルにフラッシュします。. ここで特定の周波数はどうですか？これが、ブラッシング戦略について言いたいことです。

知らせ：REDO ログ バッファを REDO ログ ファイルにフラッシュするプロセスは、実際にはディスクにフラッシュされません。== ファイル システム キャッシュ (ページ キャッシュ) == (これは、ファイルの書き込み効率を向上させるために最新のオペレーティング システムによって行われた最適化です) をブラッシングするだけで、実際の書き込みはシステムの決定に委ねられます (ページ キャッシュが十分大きい）。次に、InnoDB の問題で、同期のためにシステムに引き渡された場合、システムがダウンした場合、データも失われます (システム全体がダウンする可能性はまだ比較的小さいですが)。

この状況では、 InnoDB はinnodb_flush_log_at_trx_commitparameters 、このパラメータは、commit がトランザクションをコミットするときに、REDO ログ バッファ内のログを REDO ログ ファイルにフラッシュする方法を制御します。. 次の 3 つの戦略をサポートしています。

• 设置为0：毎回という意味トランザクションのコミット時にフラッシュ操作を実行しない. (システムのデフォルトでは、1 秒ごとに REDO ログを同期するようにマスター スレッドが設定されます)
• 设置为1: トランザクションがコミットされるたびに同期が実行され、ディスク操作が実行されることを示します (デフォルト値)。
• 设置为2: トランザクションがコミットされるたびに同期せずに REDO ログ バッファの内容のみをページ キャッシュに書き込む. によるOS がディスク ファイルと同期するタイミングを決定します。。

mysql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

さらに、InnoDB ストレージ エンジンには、時々ファイル システム キャッシュ ( ) にコンテンツを1秒書き込み、ディスク操作を呼び出すバックグラウンド スレッドがあります。redo log bufferpage cache

• バックグラウンド スレッドのフラッシュ: つまり、redo logトランザクションをコミットしていないレコードもフラッシュされる可能性があります。トランザクションの実行中redo log bufferに、これらの REDO ログ レコードは后台线程フラッシュされます。
• ブラッシングのしきい値を超える: 1 秒あたりのバックグラウンド スレッドのポーリング操作に加えて1次、別の状況があり、redo log buffer占有スペースが半分に達しようとしているときinnodb_log_buffer_size(このパラメーターはデフォルトで 16M です)、バックグラウンド スレッドは積極的にディスクを更新します。

1 さまざまな戦略のフローチャート分析

innodb_flush_log_at_trx_commit=1

概要: innodb_flush_log_at_trx_commit=1

1 の場合、トランザクションが正常にコミットされている限り、REDO ログ レコードはハードディスクに格納されている必要があり、データが失われることはありません。

トランザクションの実行中に MySQL がハングまたはダウンした場合、ログのこの部分は失われますが、トランザクションはコミットされないため、ログが失われても損失はありません。ACID D は保証でき、データが失われることはありませんが、効率は最悪です。

デフォルト値を使用することをお勧めします. オペレーティング システムのダウンタイムの確率は、理論的にはデータベースのダウンタイムよりも低くなりますが、一般的にトランザクションが使用されるため、データ セキュリティは比較的重要です.

innodb_flush_log_at_trx_commit=2

概要innodb_ flush_ log_at_trx_ commit =2

2 の場合、トランザクションが正常にコミットされている限り、REDO ログ バッファの内容はファイル システム キャッシュ (ページ キャッシュ) にのみ書き込まれます。

MySQL だけがダウンしている場合はデータの損失はありませんが、OS がダウンしている場合は 1 秒間データが失われる可能性があり、この場合は ACID の D を満たすことができません。しかし、2 の値が間違いなく最も効率的です。

innodb_flush_log_at_trx_commit=0

概要innodb_flush_log_at_trx_commit =0

0 の場合、マスタースレッドで 1 秒ごとに REDO ログの fsync が実行されます (ファイルのメモリ内部分をディスクに書き戻す) 操作であるため、インスタンスのクラッシュによって最大 1 秒以内にトランザクションが失われます。(マスター スレッドは、データの一貫性を確保するために、バッファー プール内のデータをディスクに非同期的に更新する役割を果たします)

値が 0 の場合、それは妥協です.その効率理論は 1 より高く、2 より低くなります.この戦略にはデータを失うリスクもあり、D は保証されません.

1.6 REDOログバッファ書き込み処理

1. 補足概念：ミニトランザクション

MySQL プット基礎となるページへのアトミック アクセスMini-Transaction略してone と呼びます。mtrたとえば、インデックスに対応する B+ ツリーにレコードを挿入するプロセスは one ですMini-Transaction。いわゆる には、mtr一連の REDO ログを含めることができます。、 進行中この一連のログは、クラッシュ リカバリ中にredo分割できない全体として使用できます。

トランザクションには複数のステートメントを含めることができます。各ステートメントは実際には複数の でmtr構成され、それぞれにmtr複数の REDO ログを含めることができます。これらの関係を示す図を次のように描きます。

2. REDO ログがログ バッファに書き込まれる

REDO ログをログ バッファに書き込むプロセスは順次実行されます。つまり、最初に前のブロックに書き込み、次にブロックの空き領域が使い果たされたときに次のブロックに書き込みます。REDO ログをログ バッファに書き込もうとするとき、最初に遭遇する問題は、どのブロックのどのオフセットに書き込むか、そのため、InnoDB の設計者は意図的にいわゆるbuf_ フリーグローバル変数、この変数は、その後に書き込まれる REDO ログをログ バッファ内のどこに書き込むかを示します。写真のように:

mtr の実行中に複数の REDO ログが生成されることがあります. これらの REDO ログは切り離せないグループであるため、実際には REDO ログが生成されるたびにログ バッファに挿入されるわけではありませんが、各 mtr の操作中に生成されたログは一時的に 1 か所に保管され、mtr が終了すると、プロセス中に生成された一連の REDO ログがログ バッファーにコピーされます。. ここで、T1 と T2 という名前の 2 つのトランザクションがあり、各トランザクションに 2 つの mtr が含まれているとします。これらの mtr に次の名前を付けます。

• トランザクション T1 の 2 つの mtr は、それぞれ mtr_T1_1 と mtr_T1_2 と呼ばれます。
• トランザクション T2 の 2 つの mtr は、それぞれ mtr_T2_1 および mtr_T2_2 と呼ばれます。

各 mtr は一連の REDO ログを生成し、スケマティック ダイアグラムを使用して、これらの mtr によって生成されるログの状況を説明します。

異なるトランザクションが并发実行されるあるため、T1 と T2 の間の mtr は交替执行. mtr が実行されると、mtr で生成された一連の REDO ログをログ バッファにコピーする必要があります。つまり、異なるトランザクションの mtr が交互にログ バッファに書き込まれる場合がありますr について、概略図を描画します (見栄えを良くするために、1 つの mtr で生成されたすべての REDO ログをまとめて描画します)。

一部の mtr は非常に大量の REDO ログを生成します。たとえば、mtr_t1_2生成された REDO ログは比較的大きな領域を占有し、ストレージに 3 ブロックを占有します。

3. REDO ログブロックの構造図

REDO ログ ブロックは、日志头、日志体、日志尾で構成されます。ログ ヘッダーは 12 バイト、ログ テールは 8 バイトを占めるため、ブロックが実際に格納できるデータは 512-12-8=492 バイトです。

ブロックが 512 バイトになるように設計されているのはなぜですか?
これはディスクのセクターに関連しています. メカニカル ディスクのデフォルトのセクターは 512 バイトです. 書き込みたいデータが 512 バイトより大きい場合, 書き込まれるセクターは複数である必要があります。次のセクターを見つけるためにディスクを回転させる必要があります。セクター A が正常に書き込まれ、セクター B が書き込まれなかった場合、2 つのセクター A と B を書き込む必要があると仮定します。になります非原子書く、そして毎回 512 バイト (セクターと同じサイズ) だけが書き込まれる場合、各書き込みはアトミックです。

実際の REDO ログは496byte のサイズで格納され、log block body図のストレージは管理情報の一部です。log block headerlog block trailer

1.7 REDO ログファイル

1. 関連パラメータ設定

• innodb_log_group_home_dir: REDOログ・ファイル・グループが配置されているパスを指定します。デフォルト値は、./データベースのデータ・ディレクトリの下にあることを意味します。MySQL のデフォルト データ ディレクトリ ( var/lib/mysql) にはib_logfile0、ib_logfile1デフォルトで と という名前の 2 つのファイルがあり、ログ バッファ内のログは、デフォルトでこれら 2 つのディスク ファイルにフラッシュされます。この REDO ログ ファイルの場所も変更できます。

• innodb_log_files_in_group: ib_logfile0、iblogfile1... iblogfilen のように、REDO ログ ファイルの数を示します。デフォルトは 2 で、最大値は 100 です。

  mysql> show variables like 'innodb_log_files_in_group';
  +---------------------------+-------+
  | Variable_name             | Value |
  +---------------------------+-------+
  | innodb_log_files_in_group | 2     |
  +---------------------------+-------+
  #ib_logfile0
  #ib_logfile1
  

• innodb_flush_log_at_trx_commit: ディスクへの REDO ログのフラッシュの戦略を制御します。デフォルトは 1 です。

• innodb_log_file_size: 単一の REDO ログ ファイルのサイズを設定します。デフォルト値は です48M。The maximum value is 512G. Note that the maximum value is a sum of all redo log series files, that (innodb_log_files_in_group * innodb_log_file_size) is a maximum value of 512G.

  mysql> show variables like 'innodb_log_file_size';
  +----------------------+----------+
  | Variable_name        | Value    |
  +----------------------+----------+
  | innodb_log_file_size | 50331648 |
  +----------------------+----------+
  

ビジネスに応じてサイズを変更して、より大きなトランザクションに対応します。以下に示すように、my.cnf ファイルを編集し、データベースを再起動して有効にします。

[root@localhost ~]# vim /etc/my.cnf
innodb_log_file_size=200M

データベース インスタンスが頻繁に更新される場合は、REDO ログの配列とサイズを適切に増やすことができます。ただし、redo ログを大きく設定しすぎることはお勧めしません.MySQL がクラッシュすると、redo ログのレコードが再実行されます.

2. ログファイル群

ディスクには複数の REDO ログがありますが、ログ ファイル グループの形式で表示されます。これらのファイルは ==ib_logfile[number]== の形式で名前が付けられ、各ファイルのサイズは同じです。

実際の REDO ログ ファイルの合計サイズは次のとおりですinnodb_log_file_size × innodb_log_files_in_group。

使用リサイクル同じ方法でREDOログファイルグループにデータを書き込んだ場合、先に書き込んだREDOログが後で書き込んだREDOログで上書きされてしまうのでしょうか? そうです！そのため、InnoDB の設計者はチェックポイントの概念を提案しました。

3.チェックポイント

ログ ファイル グループ全体には、write pos、checkpoint という 2 つの重要な属性があります。

• write pos現在のレコードの位置です。書き込み中に後方に移動します
• checkpoint消去する現在の位置であり、後方にも移動されます

ログファイル群にREDOログが記録されるたびに、書き込み位置が遡って更新されます。MySQL がログ ファイル グループをロードしてデータを復元するたびに、ロードされた REDO ログ レコードがクリアされ、チェック ポイントが更新のために戻されます。. write pos と checkpoint の間の空の部分を使用して、新しい REDO ログ レコードを書き込むことができます。

書き込み位置がチェックポイントに追いつく場合は、ログ ファイル グループがいっぱいであり、現時点で新しい REDO ログ レコードを書き込むことができないことを意味します.MySQL は停止し、いくつかのレコードをクリアし、チェックポイントを進める必要があります.

1.9 REDO ログの要約

InnoDB の更新操作は、ログ先行書き込み(ログ前の永続化) 戦略を採用しています。つまり、ログが最初に書き込まれ、次にディスクに書き込まれます。

2.取り消しログ

2.1 Undo ログの見方

トランザクションは保証される必要があります原子性 。つまり、トランザクション内の操作がすべて完了しているか、何も行われていないかのいずれかです。ただし、トランザクションの実行中に次のような状況が発生することがあります。

• 状況 1: トランザクションの実行中に 、 、または突然発生したエラーなど、さまざまなエラーが発生する可能性があり 服务器本身的错误ます。操作系统错误断电
• ケース 2: プログラマーは、トランザクションの実行中にROLLBACKステートメントを、現在のトランザクションの実行を終了できます。

上記の状況が発生した場合、データを元の状態に戻す必要があります.このプロセスは と呼ばれます.回滚これは、誤った印象を与える可能性があります.このトランザクションは何もしていないように見えるため、原子性要件を..

2.2 Undo ログの役割

• 機能 1: データのロールバック

• 役割 2: MVCC

元に戻すのもう 1 つの役割は MVCC です。つまり、InnoDB ストレージ エンジンでの MVCC の実装は元に戻すことによって行われます。ユーザーがレコードの行を読み取るときに、レコードが他のトランザクションによって占有されている場合、現在のトランザクションは、元に戻すことによって以前の行のバージョン情報を読み取って、非ロック読み取りを実現できます。

2.3 アンドゥの格納構造

1. ロールバック セグメントと元に戻すページ

InnoDB はセグメント化されたアプローチを使用して元に戻すログ管理、つまり回滚段（rollback segment）. 各ロールバック セグメント1024が記録されundo log segment、アプリケーションは各 Undo ログ セグメントでundo页作成されます。

• (バージョン 1.1 を除く)では InnoDB1.1版本之前、ロールバック セグメントが 1 つしかないため、サポートされる同時オンライン トランザクションの数は に制限されます1024。ほとんどのアプリケーションでは十分ですが。
• バージョン 1.1 以降、InnoDB が最大のサポートを提供している128个rollback segmentため、同時オンライン トランザクションの制限が に引き上げられました128*1024。

mysql> show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_undo_logs | 128   |
+------------------+-------+

2. ロールバック セグメントとトランザクション

1. 各トランザクションは 1 つのロールバック セグメントのみを使用し、1 つのロールバック セグメントが同時に複数のトランザクションを処理する場合があります。
2. トランザクションが開始されると、ロールバック セグメントが作成されます。トランザクション中にデータが変更されると、元のデータがロールバック セグメントにコピーされます。
3. ロールバック セグメントでは、トランザクションは、トランザクションが終了するか、すべての領域が使い果たされるまで、エクステントを満たし続けます。現在のエクステントが十分でない場合、トランザクションはセグメント内の次のエクステントの拡張を要求します。割り当てられたすべてのエクステントが使い果たされると、トランザクションは元のエクステントを上書きするか、ロールバック セグメントで許可されている場合は新しいエクステントを拡張します。使用するパネル。
4. ロールバック セグメントが UNDO テーブルスペースに存在します。データベースには複数の UNDO テーブルスペースが存在できますが、一度に使用できる UNDO テーブルスペースは 1 つだけです。

mysql> show variables like 'innodb_undo_tablespaces';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| innodb_undo_tablespaces | 2     |
+-------------------------+-------+
# undo log的数量，最少为2. undo log的truncate操作有purge协调线程发起。在truncate某个undo log表空间的过程中，保证有一个可用的undo log可用。

5. トランザクションがコミットされると、 InnoDB ストレージ エンジンは次の 2 つのことを行います。
   • 後で消去操作を行うために、元に戻すログをリストに入れます
   • 次のトランザクションに割り当てることができる場合、元に戻すログが配置されているページを再利用できるかどうかを判断します

3. ロールバック セグメントのデータ分類

1. 未提交的回滚数据(uncommitted undo information): データに関連付けられたトランザクションは、読み取りの一貫性を実現するためにコミットされていないため、他のトランザクションからのデータによってデータを上書きすることはできません。
2. 已经提交但未过期的回滚数据(committed undo information): このデータに関連付けられたトランザクションは送信されましたが、元に戻す保持パラメータの保持時間の影響を受けています。
3. 事务已经提交并过期的数据(expired undo information): トランザクションはコミットされており、データ保持期間は期限切れデータに属する元に戻す保持パラメータで指定された時間を超えています。ロールバック セグメントがいっぱいになると、「コミットされて期限切れになったデータ」が最初に上書きされます。

トランザクションがコミットされた後、元に戻すログと元に戻すログが配置されているページをすぐに削除することはできません。これは、元に戻すログを介して行レコードの以前のバージョンを取得する必要がある他のトランザクションが存在する可能性があるためです。トランザクションの送信時に、undo ログをリンク リストに入れます。undo ログが最終的に削除されるかどうかは、undo ログが配置されているページのパージ スレッドによって判断されます。

2.4 アンドゥの種類

InnoDB ストレージ エンジンでは、元に戻すログは次のように分割されます。

• 元に戻すログを挿入

  挿入操作はトランザクション自体にしか見えないため、トランザクションがコミットされた直後に取り消しログを削除できます。パージ操作は必要ありません。

• アンドゥログを更新

  元に戻すログは、MVCC メカニズムを提供する必要がある場合があるため、トランザクションがコミットされたときに削除できません。送信時に元に戻すログのリンクされたリストに入れます、パージスレッドが最終的な削除を行うのを待っています。

2.5 アンドゥログのライフサイクル

2.5 アンドゥログのライフサイクル

1. 簡単な生成プロセス

以下は、元に戻す + やり直しトランザクションの単純化されたプロセスです。

A=1 と B=2 という 2 つの値があるとします。次に、A を 3 に、B を 4 に変更します。

[外部リンクの画像転送に失敗しました。ソース サイトには盗難防止リンクのメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-9nCO77oG-1660305915965) (D:\note\note Warehouse\picture\image- 20220711162414928.png)]

Buffer Pool のプロセスのみ:

Redo ログと Undo ログを使用する場合:

バッファ プールのデータを更新する前に、まずデータ トランザクションの状態を Undo ログに書き込む必要があります。更新の途中でエラーが発生したと仮定すると、Undo Log を使用して、トランザクションが開始される前にロールバックできます。

2. 詳細な生成プロセス

INSERT を実行すると、次のようになります。

begin;
INSERT INTO user (name) VALUES ("tom");

挿入されたデータは元に戻すログ ログを生成し、ロールバック ポインターはこのログを指します。

元に戻すログには、元に戻すログのシリアル番号、主キーに挿入された列と値が記録されます...その後、ロールバック時に、対応するデータを主キーを介して直接削除できます。

UPDATE を実行すると、次のようになります。

更新に対応する操作は、更新の取り消しログを生成し、次のように分割されます。主キーを更新し、主キーを更新しない、今実行すると仮定します：

UPDATE user SET name="Sun" WHERE id=1;

このとき入れます古いレコードは新しい取り消しログに書き込まれます、させてロールバック ポインタが新しい取り消しログを指している、元に戻す番号は 1 で、新しい元に戻すログは古い元に戻すログを指します (元に戻す番号 = 0)。

ここで実行するとします:

UPDATE user SET id=2 WHERE id=1;

主キーの更新操作では、元データの削除マークフラグが最初に開かれます、この時点では、データの実際の削除はなく、実際の削除はクリーニングスレッドに渡されて判断されます。後で新しいデータを挿入すると、新しいデータも元に戻すログを生成します、および取り消しログのシーケンス番号が増加します。

データが変更されるたびにアンドゥ ログが生成されることがわかります.レコードが複数回変更されると、複数のアンドゥ ログが生成されます.アンドゥ ログには、変更前のログと、各アンドゥのシリアル番号が記録されます.ログは増分であるため、ロールバックする場合は、依次向前推シリアル番号に従って元のデータを見つけることができます。

3. undo ログのロールバック方法

上記の例を例にとると、ロールバックが実行されると仮定すると、対応するプロセスは次のようになります。

1. undo no=3 のログから id=2 のデータを削除
2. undo no=2 ログを使用して、id=1 のデータの削除マークを 0 に復元します。
3. undo no=1 ログを使用して、id=1 のデータの名前を Tom に復元します。
4. undo no=0 log で id=1 のデータを削除します

4. ログの削除を元に戻す

• 取り消しログの挿入用

  挿入操作の記録があるため、トランザクション自体にのみ表示され、他のトランザクションには表示されません. したがって、パージ操作なしで、トランザクションがコミットされた直後に取り消しログを削除できます。

• 更新取り消しログ用

  元に戻すログは、MVCC メカニズムを提供する必要がある場合があるため、トランザクションがコミットされたときに削除できません。送信時に元に戻すログのリンクされたリストに入れ、パージ スレッドが最終的な削除を実行するのを待ちます。

補充:

パージスレッドの 2つの主な機能は次のとおりです清理undo页。清理pageDelete_Bit. InnoDB では、トランザクションの Delete 操作は実際にはデータ行を削除しませんが、レコードを削除せずにレコードの Delete_Bit をマークする Delete Mark 操作です。これは一種の「偽の削除」であり、単なる目印であり、実際の削除作業はバックグラウンド パージ スレッドによって完了する必要があります。

2.6 まとめ

undo ログは論理ログです。トランザクションをロールバックすると、データベースは論理的に元の状態に復元されます。

REDO ログは物理的なログです。データページの物理的な変更を記録します、undo ログは redo ログの逆プロセスではありません。

3.ビンログ

Binlog は MySQL で最も重要高度な。

Binlog は、更新ログとも呼ばれるバイナリ ログ、バイナリ ログ ファイルです。データベースおよびその他のデータベース更新イベントによって実行されたDDLすべてのステートメントを記録しますが、データを変更しないステートメント (データ クエリ ステートメントの select、show など) は含まれません。DML

これは==イベント フォーム==に記録され、保存されます二进制文件。これらの情報により、データ更新操作の全プロセスを再現できます。

すべてのステートメントをログに記録する場合 (たとえば、問題のあるクエリを特定するため)、次を使用する必要があります。一般的なクエリ ログ。

binlog の主な適用シナリオ

• データ復旧: MySQL データベースが予期せず停止した場合、binlog を使用して、ユーザーが実行した操作を照会できます。次に、バイナリ ファイルのレコードに基づいてデータベース サーバーを復元します。

• データ複製: マスター/スレーブ レプリケーション アーキテクチャでは、マスター サーバーはバイナリ ファイルをスレーブ サーバーに送信し、ログを中継することでデータの一貫性を実現します。

  リレーログはマスタースレーブサーバーアーキテクチャのスレーブサーバーにのみ存在し、バイナリログの内容をマスターサーバーから読み取り、読み取った情報本地的日志文件を に、スレーブサーバーのローカルログファイルが呼び出されます中继日志。次に、サーバーから中継ログを読み取り、中継ログの内容に従ってスレーブサーバーのデータを更新し、マスターサーバーとスレーブサーバーのデータ同期を完了します。

書き込みメカニズム

binlogの書き込みタイミングも非常にシンプルで、トランザクション実行中、最初にログを binlog キャッシュに書き込みます、トランザクションがコミットされると、次に、binlog キャッシュを binlog ファイルに書き込みます. トランザクションのバイナリログは逆アセンブルできないため、トランザクションがどんなに大きくても一度書き込む必要があるため、システムはメモリのブロックを各スレッドにバイナリログキャッシュとして割り当てます。

We can binlog_cache_sizecontrol the size of a single thread binlog cache through parameters. ストレージの内容がこのパラメーターを超えると、一時的にディスクに保存されます (スワップ)

• 上図の書き込みは、ファイルシステムのページキャッシュにログを書き込むことを指し、データをディスクに永続化しないため、速度は比較的高速です
• 上の図の fsync は、データをディスクに永続化する操作です。

点滅戦略について: 書き込みと fsync のタイミングはパラメーターによってsync_binlog制御され。

• デフォルトは0: 0 の場合、トランザクションが送信されるたびに書き込みのみを行い、システムがいつ fsync を実行するかを判断することを意味します。(fsync 中のシステム ダウンタイムはデータ損失の原因となります)
• に設定1: トランザクションがコミットされるたびに、redo ログのフラッシュ プロセスと同様に fsync が実行されることを示します。
• N (N>1) に設定できる妥協点があります。これは、トランザクションが送信されるたびに書き込みを行うことを意味しますが、N 個のトランザクションが蓄積された後にのみ fsync を実行することを意味します。

binlog と redolog の比較

• redo log です物理日志、記録内容は「あるデータページにどのような変更が加えられたか」で、InnoDBストレージエンジン層に属します。
• binlog の場合逻辑日志、レコードの内容はステートメントの元のロジックであり、MySQL Server レイヤーに属する「行 ID=2 の c フィールドに 1 を追加する」に似ています。
• それらはすべて永続性の保証に属しますが、強調する点は異なります。
  • REDO ログにより、 InnoDB ストレージ エンジンはクラッシュ リカバリ機能を持つことができます。
  • Binlog は、MySQL クラスター アーキテクチャのデータの一貫性を保証します。

二相コミット

REDO ログはトランザクションの実行中に常に書き込まれますが、UNDO ログはトランザクションがコミットされたときにのみディスクに書き込む必要があります。この時点でクラッシュすると、元に戻すログのデータが失われます。この目的のために、2 フェーズのトランザクション コミットが提案されています。

REDO ログの書き込みは、準備とコミットの 2 つのステップに分割されます。これは2 フェーズ コミットです。

2 フェーズ コミットを使用した後、binlog への書き込みが影響しない場合に例外が発生しますこれは、MySQL が REDO ログ ログに従ってデータを復元するときに、REDO ログがまだ準備段階にあり、対応する binlog ログがないことが判明したため、トランザクションをロールバックするためです。

コミット フェーズ中に REDO ログで例外が発生し、トランザクションがロールバックされない: MySQL はトランザクション ID を介して対応する binlog ログを見つけることができるため、MySQL は、トランザクションが完了したと判断した場合、データを復元するためにトランザクションを送信します。