mysql ログ ファイルの undo ログと redo ログを設定する方法

1 undo

1.1 undo とは

undo ログは、変更前のデータを保存するために使用されます。 tba テーブルの id=2 の行データが変更され、Name='B' が Name='B2' に変更されたと仮定すると、Undo ログは Name='B' のレコードを保存するために使用されます。この変更で例外が発生した場合は、Undo ログを使用してロールバック操作を実装し、トランザクションの一貫性を確保できます。

データ変更操作は主にINSERT UPDATE DELETEであり、UNDO LOGは挿入された一意のキー値を記録するINSERT_UNDO(INSERT操作)とUPDATE_UNDO(UPDATEとDELETEを含む)の2種類に分かれます。 DELETE 操作)、変更された一意のキー値と古い列レコードを記録します。

#Id名前1A2B#3C4

1.2 undo パラメータ

MySQL には、undo に関連する次のパラメータ設定があります:

mysql> show global variables like '%undo%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 |
| innodb_undo_directory    | ./         |
| innodb_undo_log_truncate | OFF        |
| innodb_undo_logs         | 128        |
| innodb_undo_tablespaces  | 3          |
+--------------------------+------------+

mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128   |
| innodb_undo_log_truncate             | OFF   |
+--------------------------------------+-------+

• innodb_max_undo_log_size

## UNDO テーブルスペース ファイルの最大サイズを制御する innodb_undo_log_truncate が開始されると、UNDO テーブルスペースが innodb_max_undo_log_size しきい値を超えた場合にのみ切り捨てが試行されます。この値のデフォルトのサイズは 1G で、切り捨て後のデフォルトのサイズは 10M です。

• innodb_undo_tablespaces

UNDO 独立表スペースの数を設定します。範囲は 0 ～ 128、デフォルトは0、0 独立した UNDO 表スペースが有効になっておらず、UNDO ログが ibdata ファイルに保管されていることを示します。このパラメータは、MySQL インスタンスの初期化時にのみ指定できます。インスタンスが作成されている場合、このパラメータは変更できません。データベース構成ファイル .cnf で指定された innodb_undo_tablespaces の数が、インスタンスの作成時に指定された数より大きい場合、起動に失敗し、パラメータ設定が間違っていることを示します。

このパラメータが n (n>0) に設定されている場合、n 個の取り消しファイル (undo001、undo002... undo n)、各ファイルのデフォルトのサイズは次のとおりです。 10M.

このパラメータを設定する必要があるのはどのような場合ですか?

DB の書き込みプレッシャーが高い場合は、独立した UNDO テーブルスペースをセットアップし、UNDO ログを ibdata ファイルから分離し、ストレージ用に innodb_undo_directory ディレクトリを指定できます。高速ディスクを使用して、UNDO LOG の読み取りおよび書き込みパフォーマンスを高速化します。

• innodb_undo_log_truncate

InnoDB のパージ スレッドは、innodb_undo_log_truncate 設定、つまり innodb_max_undo_log_size のパラメータ値に従ってオンまたはオフになります。 、周波数を切り詰めて領域の再利用を実行し、ファイルの再初期化を元に戻します。

このパラメーターが有効になる前提条件は、独立表スペースがセットアップされており、独立表スペースの数が 2 以上であることです。

UNDO ログ ファイルの切り捨てのプロセスでは、パージ スレッドはファイルにアクティブなトランザクションがあるかどうかを確認する必要があります。ない場合は、UNDO ログ ファイルを割り当て不可としてマークする必要があります。 、UNDO ログは他のファイルに記録されるため、切り捨て操作を実行するには少なくとも 2 つの独立した表スペース ファイルが必要です。割り当て不可としてマークした後、独立したファイル undo__trunc.log が作成され、特定のファイルが記録されます。 UNDO ログ ファイルは現在切り捨てられています。その後、UNDO ログ ファイルの 10M への初期化が開始されます。操作が完了したら、切り捨てアクションを表す undo__trunc.log ファイルを削除します。このファイルにより、失敗した場合でも、切り捨てプロセス中にこのエラーが発生すると、データベース サービスが再起動されます。再起動後、サービスはこのファイルを検出し、切り捨て操作を完了し続けます。ファイルを削除すると、UNDO ログ ファイルは割り当て可能としてマークされます。

• innodb_purge_rseg_truncate_frequency

は、ロールバック セグメントをパージする頻度を制御するために使用されます。デフォルトは 128 です。これが n に設定されていると仮定すると、Innodb Purge 操作の調整スレッドがトランザクションを 128 回パージすると、履歴パージがトリガーされて、現在の UNDO ログ テーブル スペースのステータスが切り捨てをトリガーするかどうかを確認することを意味します。

1.3 UNDO スペース管理

独立表スペースを設定する必要がある場合は、データベース・インスタンスの初期化時に独立表スペースの数を指定する必要があります。

UNDO は内部的に複数のロールバック セグメント (ロールバック セグメント) で構成されており、合計 128 個が ibdata システム テーブル スペースに保存されます。各 resg スロット、つまり各ロールバック セグメントは内部的に 1024 個のアンドゥ セグメントで構成されます。

ロールバック セグメントは次のように割り当てられます:

• スロット 0、システム テーブル スペース用に予約;

• スロット 1 -32 は一時表スペース用に予約されています。データベースが再起動されるたびに、一時表スペースは再構築されます。独立した表スペースがある場合は、

• slot33-127 が予約されます。 UNDO 独立表スペース。そうでない場合は、システム表スペース用に予約します。

一時表トランザクション用に 32 個のロールバック セグメントを削除し、残りの 128-32= 96 個のロールバック セグメントで 96* を実行できます。 1024 の同時トランザクション操作。各トランザクションは 1 つのアンドゥ セグメント スロットを占有します。トランザクションに一時テーブル トランザクションがある場合は、一時テーブル スペース内の別のアンドゥ セグメント スロットが占有されることに注意してください。セグメント スロットは、2 つのアンドゥ セグメント スロットを占有します。存在する場合:

元に戻すログ用の空きスロットが見つかりません。 は、同時トランザクションが多すぎるため、業務を転用するかどうかを検討する必要があることを意味します。

ロールバック セグメントは、ポーリング スケジューリングを使用して割り当てられます。独立表スペースが設定されている場合、システム表スペースのロールバック セグメント内の UNDO セグメントは使用されず、独立表が使用されます。スペース、同時に、ルックバック セグメントが Truncate 操作中の場合、そのセグメントは割り当てられません。

2 redo

2.1 redo とは

データベースがデータを変更すると、データ ページは、ディスクからバッファ プールに読み取られてから、バッファ プール内で変更される必要があります。この時点では、バッファ プール内のデータ ページは、ディスク上のデータ ページの内容と不一致になります。バッファ プール内のデータはダーティ ページと呼ばれます。この時点で DB サービスの異常な再起動が発生した場合、データはまだメモリ内になく、ディスク ファイルと同期されていません (ディスク ファイルとの同期はファイルが存在する場合、バッファ プール内のデータ ページが変更されると、対応する変更レコードがこのファイルに記録される可能性があります (ログの記録は行われないことに注意してください)。シーケンシャル IO) を実行すると、DB サービスがクラッシュして DB が復元されたときに、このファイルの記録内容に基づいてディスク ファイルに再適用することもでき、データの一貫性が維持されます。

このファイルは REDO ログであり、変更されたデータを順番に記録するために使用されます。

• バッファ プール内のダーティ ページがディスクに更新されていない場合、クラッシュが発生します。サービスを開始すると、必要なページを見つけることができます。ディスク ファイルの記録;

• バッファ プール内のデータはディスク ファイルに直接フラッシュされますが、これはランダム IO であり、効率が悪くなります。 、バッファ プール内のデータを REDO ログに記録することは、シーケンシャル IO でトランザクション送信の速度を向上させることができます;

tba テーブルの id=2 の行データが次のとおりであると仮定します。変更され、Name='B' が Name = 'B2' に変更されると、REDO ログが Name='B2' のレコードを保存するために使用されます。この変更がディスク ファイルにフラッシュされるときに例外が発生した場合、REDO ログはログを使用してやり直し操作を実装し、トランザクションの耐久性を確保できます。

	D

#Id名前1A2B#3C4

REDO ログとバイナリ ログの違いに注意してください。REDO ログはストレージ エンジン層によって生成され、バイナリ ログはデータベース層によって生成されます。大規模なトランザクションが 100,000 行のレコードを tba に挿入するとします。このプロセス中、レコードは REDO ログに連続して連続して記録されますが、バイナリ ログには記録されません。トランザクションがコミットされた場合にのみ、トランザクションはバイナリ ログ ファイルに書き込まれます。一度、真ん中。バイナリログにはロウログ、ステートメントログ、混合ログの 3 種類の記録形式があり、それぞれ記録形式が異なります。

#2.2 redo パラメータ

• ##innodb_log_files_in_group

  REDO ログ ファイルの数、命名方法 (例: ib_logfile0、iblogfile1... iblogfilen)。デフォルトは 2 で、最大値は 100 です。

innodb_log_file_size

• ファイル設定のサイズ、デフォルト値は 48M、最大値は 512G です。注意してください。最大値が指すもの REDO ログ シリーズ ファイル全体の合計です。つまり、(innodb_log_files_in_group * innodb_log_file_size) は最大値 512G を超えることはできません。

innodb_log_group_home_dir

• ファイル ストレージ パス

innodb_log_buffer_size

• #REDO ログ キャッシュ領域 (デフォルトは 8M) は 1 ～ 8M に設定できます。ディスクへのトランザクション ログの書き込みを遅らせ、REDO ログをバッファに入れてから、 innodb_flush_log_at_trx_commit パラメータの設定に従ってバッファからディスクにログをフラッシュします。

innodb_flush_log_at_trx_commit

• #innodb_flush_log_at_trx_commit=1、各コミットは REDO ログを REDO ログから変更しますバッファはシステムに書き込まれ、fsync 経由でディスク ファイルにフラッシュされます。

• innodb_flush_log_at_trx_commit=2、トランザクションが送信されるたびに、MySQL はログを REDO ログ バッファからシステムに書き込みますが、それをファイル システム バッファに書き込み、fsync するだけです。システム内からディスクにコピーします。データベース インスタンスがクラッシュしても、REDO ログは失われませんが、サーバーがクラッシュすると、ファイル システム バッファがディスク ファイルと fsync する時間がないため、データのこの部分は失われます。

• innodb_flush_log_at_trx_commit=0、トランザクション プロセス中、ログは他の設定と同様に常に REDO ログ バッファーにありますが、トランザクションがコミットされると、REDO 書き込み操作は発生しません。 MySQL 内で 1 秒に 1 回動作して、REDO ログ バッファからシステムにデータを書き込みます。クラッシュが発生すると、1 秒以内のトランザクション変更操作は失われます。

• 注: プロセス スケジューリング ポリシーの問題により、この「フラッシュ (ディスクへのフラッシュ) 操作を 1 秒に 1 回実行する」は 100% の「1 秒あたり」を保証するものではありません。 。

2.3

redo

スペース管理

やり直しログ ファイルの名前は ib_logfile[number] です。REDO ログは順次ファイルに書き込みます。いっぱいになると、最初のファイルに戻って上書きします。 (ただし、REDO チェックポイントを実行すると、最初のログ ファイルのヘッダー チェックポイント マークも更新されるため、厳密にはシーケンシャル書き込みとしてカウントされません)。 実際、REDO ログは、REDO ログ バッファと REDO ログ ファイルの 2 つの部分で構成されています。バッファ プールでは、データの変更は REDO ログ バッファに記録されます。次の状況が発生した場合、REDO ログは REDO ログ ファイルにフラッシュされます:

REDO ログ バッファの領域が不十分です

トランザクションの送信 (innodb_flush_log_at_trx_commit パラメーターの設定に依存します)
バックグラウンド スレッド
チェックポイントを実行します
シャットダウンの例
binlog 切り替え
##3 元に戻すトランザクションとやり直しトランザクションを記録する方法
3.1 Undo Redo トランザクションの簡略化されたプロセス

2 つのデータ A と B があり、それぞれ値 1 と 2 があると仮定します。トランザクションの操作内容は、modify 1 を 3、2 を 4 に変更すると、実際のレコードは次のようになります (簡略化):

A. トランザクション開始.

B. A=1 を記録してログを元に戻します。

C. A=3 を変更します。

D. A=3 を記録してログをやり直します。

E. レコード B= 2 を元に戻します。

F. B= 4 を変更します。

G. B=4 をやり直しログに記録します。

H. REDO ログをディスクに書き込みます。

I. トランザクションの送信

3.2 IO への影響

Undo Redo を設計する主な目的は、入出力のパフォーマンスを向上させ、処理能力を向上させることです。データベースの。 B D E G H はすべて新しい操作であることがわかりますが、B D E G はバッファ領域にバッファリングされています。G のみ IO 操作が追加されています。Redo ログの IO パフォーマンスを向上させるために、InnoDB の Redo ログの設計には次の機能があります。

B. REDO ログが連続した領域に保存されるようにしてください。したがって、システムの初回起動時には、ログ ファイルのスペースが完全に割り当てられます。パフォーマンスを向上させるために、Redo ログはシーケンシャル IO 方式で記録され、段階的に完了します。

B. ログをバッチで書き込みます。ログはファイルに直接書き込まれず、最初に REDO ログ バッファに書き込まれます。ログをディスクにフラッシュする必要がある場合 (トランザクションの送信など)、多くのログがまとめてディスクに書き込まれます。

C. 同時トランザクション REDO ログの記憶領域を共有し、文の実行順序に従って交互に REDO ログをまとめて記録し、ログが占有する領域を削減します。たとえば、REDO ログのレコードの内容は次のようになります。

レコード 1:
Record 2:
レコード 3:
レコード 4:
レコード 5:

# D. C のため、トランザクションが REDO ログをディスクに書き込むと、コミットされていない他のトランザクションのログもディスクに書き込まれます。

E. REDO ログでは順次追加操作のみが実行されます。トランザクションをロールバックする必要がある場合、その REDO ログ レコードは REDO ログから削除されません。

3.3 リカバリ

前述したように、コミットされていないトランザクションとロールバックされたトランザクションもREDOログに記録されるため、リカバリする場合、これらのトランザクションは特別に処理する必要があります。加工の。 2 つの異なるリカバリ戦略があります。

A. リカバリするときは、コミットされたトランザクションのみをやり直します。

リカバリを実行する場合、コミットされていないトランザクションやロールバックされたトランザクションを含むすべてのトランザクションを再実行する必要があります。次に、コミットされていないトランザクションを、Undo Log を通じてロールバックします。

MySQL データベース InnoDB ストレージ エンジンは戦略 B を使用します。

InnoDB ストレージ エンジンの回復メカニズムにはいくつかの特徴があります:

A. Redo ログを再実行するとき、および トランザクション性は気にしないでください

。リカバリ中は、BEGIN、COMMIT、ROLLBACK の動作は行われません。各ログがどのトランザクションに属しているかは関係ありません。 REDOログにはトランザクションIDなどのトランザクションに関する内容が記録されますが、これらの内容は操作対象となるデータの一部としてのみ扱われます。

B. 戦略 B を使用する場合は、Undo ログを永続化し、REDO ログを書き込む前に、対応する Undo ログをディスクに書き込む必要があります。 Undo と Redo Log のこの関係により、永続性が複雑になります。複雑さを軽減するために、InnoDB は Undo ログをデータとして扱うため、Undo ログを記録する操作も REDO ログに記録されます。 UNDO ログをメモリにキャッシュすることにより、REDO ログを書き込む前にディスクに書き込む必要がなくなります。

Undo ログ操作を含む Redo ログは次のようになります:

Record 1: Undo log insert

> ;
レコード 2: レコード 3: 元に戻すログの挿入
>
レコード 4: レコード 5:
元に戻すログの挿入
> レコード 6: < ;trx3 、削除 …>
C. 現時点では、まだ不明な点が残っています。 Redoはトランザクションではないので、ロールバックしたトランザクションを再実行することはできないのでしょうか？

確かにその通りです。同時に、Innodb はトランザクションのロールバック中の操作を REDO ログに記録します。ロールバック操作は基本的にデータも変更するため、ロールバック操作を実行すると、データへの変更が REDO ログに記録されます。

ロールバックされたトランザクションの Redo ログは次のようになります:

レコード 1: >

レコード 2: insert A

…>
レコード 3: > レコード 4: < ;trx1, update B
…>
レコード 5: > レコード 6: delete C
…>
レコード 7: insert C>
レコード 8: B を古い値に更新>
レコード 9: delete A>

ロールバックされたトランザクションの回復操作は、最初にやり直してから元に戻すことなので、データの整合性は破壊されません。 。

	D

以上がmysql ログ ファイルの undo ログと redo ログを設定する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。