MySQL の基本 (33) MySQL トランザクションログ

トランザクションには、原子性、一貫性、分離性、耐久性という 4 つの特性があります。では、取引の4つの特徴はどのような仕組みに基づいているのでしょうか？

トランザクションの分離は锁机制によって実現されます。
トランザクションのアトミック性、一貫性、耐久性は、トランザクションの REDO ログと UNDO ログによって保証されます。
- REDO LOG はと呼ばれ重做日志、再書き込み操作を提供し、送信されたトランザクションによって変更されたページ操作を復元し、トランザクションの耐久性を確保するために使用されます。
- 回滚日志UNDO LOG は、トランザクションのアトミック性と一貫性を確保するために、行レコードを特定のバージョンにロールバックすることと呼ばれます。

DBA の中には、UNDO が REDO の逆のプロセスであると考える人もいますが、そうではありません。

1.やり直しログ

1.1 REDO ログが必要な理由

一方で、バッファプールは CPU とディスク間のギャップをなくすのに役立ち、チェックポイントメカニズムはデータの最終配置を保証しますが、チェックポイントのため、マスタースレッドは一定の間隔でデータを処理します并不是每次变更的时候就触发。したがって、最悪のシナリオは、トランザクションがコミットされた後、バッファープールに書き込まれたばかりでデータベースがダウンし、このデータが失われ、回復できなくなることです。

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

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

另一个解决的思路: 送信されたトランザクションによってデータベース内のデータに加えられた変更を永続的に有効にしたいだけです。後でシステムがクラッシュしたとしても、この変更は再起動後に復元できます。したがって、実際には、トランザクションがコミットされるたびに、トランザクションによってメモリ内で変更されたすべてのページをディスクに更新する必要はなく、変更される内容のみを変更する必要があり修改ます记录一下。たとえば、トランザクションは、第10号システム表スペースのオフセットにある100バイトの値を1に変更します2。記録する必要があるのは、表スペース 0 のページ 10 のオフセット 100 の値を 2 に更新することだけです。
ここに画像の説明を挿入します

1.2 REDO ログの利点と特徴

1. メリット

REDO ログにより、ディスクフラッシュの頻度が減少します。
REDO ログが占有するスペースはほとんどありません

2. 特徴

REDO ログはディスクに順番に書き込まれます
トランザクション実行中、REDO ログが継続的に記録されます

1.3 REDOの構成

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

重做日志的缓冲 (redo log buffer)はメモリに保存されており、揮発性です。

パラメータ設定: 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 ログファイル (REDO ログファイル) は永続的です。

1.4 やり直しの全体的なプロセス

更新トランザクションを例にとると、REDO ログフロープロセスは次の図に示すようになります。
ここに画像の説明を挿入します

ステップ1: まず、元のデータをディスクからメモリに読み取り、データのメモリコピーを変更します
ステップ 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_commitcommit がトランザクションをコミットするときに、REDO ログバッファ内のログを REDO ログファイルにフラッシュする方法を制御するパラメータを提供します。次の 3 つの戦略がサポートされています。

设置为0: トランザクションが送信されるたびにフラッシュ操作が実行されないことを示します。(システムのデフォルトでは、マスタースレッドが 1 秒ごとに REDO ログを同期します)
设置为1: トランザクションが送信されるたびに同期とディスクのフラッシュ操作が実行されることを示します ( 默认值)
设置为2: トランザクションが送信されるたびに、同期せずに REDO ログバッファの内容のみがページキャッシュに書き込まれることを示します。いつディスクファイルと同期するかは OS によって決定されます。

1.6 さまざまなブラッシング戦略のデモンストレーション

1. フローチャート
ここに画像の説明を挿入します

ここに画像の説明を挿入します

1.7 REDO ログファイル

1. 関連パラメータの設定

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

innodb_log_files_in_group: REDO ログファイルの数を指定します。命名方法は ib_logfile0、iblogfile1...iblogfilen です。デフォルトは 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。最大値は 512G です。最大値は REDO ログシリーズファイル全体の合計を指すことに注意してください。つまり、(innodb_log_files_in_group * innodb_log_file_size) は最大値 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

2. ログファイルグループ

ここに画像の説明を挿入します
実際の REDO ログファイルの合計サイズは次のとおりですinnodb_log_file_size × innodb_log_files_in_group。

REDO ログファイルグループに循環的にデータを書き込むと、後で書き込まれた REDO ログが先に書き込まれた REDO ログを上書きしますか? 確かに！そこで、InnoDB の設計者はチェックポイントの概念を提案しました。

3. チェックポイント
ここに画像の説明を挿入します
書き込みポスがチェックポイントに追いついた場合、チェック日志文件组ポイントがいっぱいであることを意味します。現時点では、新しい REDO ログレコードを書き込むことはできません。MySQL は停止し、いくつかのレコードをクリアして、チェックポイントを進める必要があります。
ここに画像の説明を挿入します

2. アンドゥログ

REDO ログはトランザクションの耐久性を保証し、UNDO ログはトランザクションのアトミック性を保証します。トランザクション内のデータを更新するための事前操作は、実際には
最初に元に戻すログを書き込むことです。

2.1 Undoログの見方

トランザクションはアトミックである必要があります。つまり、トランザクション内のすべての操作が完了するか、何も行われない必要があります。ただし、トランザクションの実行途中で次のような状況が発生する場合があります。

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

上記の状況が発生した場合、データを元の外観に戻す必要があります。このプロセスは "トランザクション" と呼ばれます。これにより、このトランザクションは何も行われていないように見えるため、要件を回滚満たしているかのような錯覚が生じる可能性があります。原子性

2.2 アンドゥログの役割

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

2.3 アンドゥの格納構造

1. セグメントのロールバックとページの取り消し

InnoDB はセグメントを使用して UNDO ログ、つまりを管理します回滚段（rollback segment）。1024各ロールバックセグメントは記録されundo log segment、各アンドゥログセグメント内にアプリケーションが作成されます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 つのロールバックセグメントは同時に複数のトランザクションを処理できます。
トランザクションが開始されると、ロールバックセグメントが作成され、トランザクション中にデータが変更されると、元のデータがロールバックセグメントにコピーされます。
ロールバックセグメントでは、トランザクションが終了するかすべての領域が使い果たされるまで、トランザクションはエクステントを埋め続けます。現在のエクステントが十分でない場合、トランザクションはセグメント内の次のエクステントの拡張を要求します。割り当てられたエクステントがすべて使用されている場合、トランザクションは元のエクステントを上書きするか、ロールバックセグメントが許可する場合は新しいエクステントを拡張します。使用するパネル。
ロールバック・セグメントはUNDO表スペースに存在します。データベース内に複数のUNDO表スペースが存在できますが、同時に使用できるUNDO表スペースは1つだけです。
トランザクションがコミットされると、InnoDB ストレージエンジンは次の 2 つのことを実行します。
- 後続のパージ操作のためにリストに元に戻すログを追加します。
- アンドゥログが存在するページが再利用可能かどうか、また次のトランザクションに割り当てられるかどうかを判断します。

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

未提交的回滚数据(uncommitted undo information)
已经提交但未过期的回滚数据(committed undo information)
事务已经提交并过期的数据(expired undo information)

2.4 アンドゥの種類

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

アンドゥログを挿入
アンドゥログを更新する

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

1. 簡単な生成プロセス

バッファプールのみが処理します:
ここに画像の説明を挿入します
Redo ログと Undo ログがある後:

ここに画像の説明を挿入します

2. 詳細な生成プロセス

ここに画像の説明を挿入します
INSERT を実行すると、次のようになります。

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

ここに画像の説明を挿入します
UPDATE を実行すると、次のようになります。

ここに画像の説明を挿入します

UPDATE user SET id=2 WHERE id=1;

ここに画像の説明を挿入します

3. アンドゥログをロールバックする方法

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

元に戻す no=3 のログを通じて id=2 のデータを削除します
undo no=2のログからid=1のデータのdeletemarkを0に戻す
undo no=1のログからid=1のデータ名をTomに復元します。
元に戻す no=0 のログを通じて id=1 のデータを削除します

4. アンドゥログの削除

挿入取り消しログの場合

挿入操作のレコードはトランザクション自体にのみ表示され、他のトランザクションには表示されないためです。したがって、UNDO ログはトランザクションの送信後に直接削除でき、パージ操作は必要ありません。
更新取り消しログの場合、
取り消しログは MVCC メカニズムを提供する必要がある場合があるため、トランザクションがコミットされたときに削除できません。送信するときは、それを元に戻すログリストに入れて、パージスレッドが最終的な削除を実行するまで待ちます。

2.6 概要

ここに画像の説明を挿入します
Undo ログは論理ログであり、トランザクションをロールバックする場合、データベースを論理的に元の状態に復元するだけです。
REDO ログは、データページの物理的な変更を記録する物理ログです。Undo ログは、REDO ログの逆のプロセスではありません。