MySQLの2段階コミット、クラッシュリカバリ、グループコミット

文書ディレクトリ

一、二段階提出

1.1 XA概念

1.2 MySQLのXA

1.3二段階提出

二、崩壊回復

2.1クラッシュリカバリプロセス

三、binlogグループ提出

3.1なぜグループ提出が必要なのか

3.2組提出原理

一、二段階提出
1.1 XAコンセプト
XA(分散トランザクション)仕様では、主にトランザクションマネージャ(TM)とリソースマネージャ(RM)の間のインタフェースが定義されます.XAは分散トランザクションを実現するために、トランザクションのコミットを2つの段階に分けます.つまり、2 PCです.XAプロトコルは、トランザクションのコミットを2つの段階に分けることで分散トランザクションを実現します.2段階:prepare段階  TMはRMにprepare命令を発行し、RMは操作し、成功するかどうかの情報をTMに返す.commitフェーズトランザクションコミットまたはロールバックフェーズは、TMがすべてのRMの成功メッセージを受信した場合、TMがRMにコミット命令を発行する.そうでなければロールバック命令を発行します.
1.2 MySQLのXA
 MySQL XAは2種類に分けられ、内部XAと外部XAである.

外部XAは複数のMySQLインスタンスにまたがる分散トランザクションに使用され、アプリケーション層がコーディネータとして介入する必要がある(クラッシュ時のサスペンショントランザクション、グローバルコミットまたはロールバックは、アプリケーション層によって決定され、アプリケーション層の実現に対する要求が高い).

内部XAは、binlogによってコーディネータとして使用される同じインスタンスの下で複数のエンジンにまたがるトランザクションに使用される.最も一般的な内部XAトランザクションはbinlogとInnoDB redoの間に存在し、主従環境のデータ整合性を保証します.

内部XAはトランザクションのコミットを2つのフェーズに分けてbinlogとredo logの一貫性の問題を解決します. MySQLは、他の非トランザクションエンジンのレプリケーションと互換性を持つために、serverレベルでbinlogを導入し、MySQLのすべてのエンジンでの変更操作を記録できるため、プライマリ・スレーブ・レプリケーション機能に使用できます.しかしbinlog,MySQLサーバ層のbinlogとinnodbエンジン層のredoの整合性の問題が導入された.
1.3二段階提出
prepareフェーズ

InnoDB prepare,prepareを持つcommit_mutex,write/sync redo log;ロールバックセグメントをPrepared状態に設定し、binlogは何もしません.

commitフェーズ

write/sync Binlog;

InnoDB commit(COMMITタグを書き込みprepare_commit_mutexを解放);

2段階コミットでbinlogの書き込みがトランザクションのコミットに成功したかどうかのフラグとして使用され、innodb commitフラグはトランザクションが成功したかどうかのフラグではありません.

innodb_support_xa：   true，    XA，             flush(prepare  flush redo log).       ，      。       binlog                  ，        slave         。     log-bin  ，                ，       innodb_support_xa  。

二、崩壊回復
2.1クラッシュ・リカバリ・プロセス

インスタンスがクラッシュからリカバリされると、アクティブなトランザクションをundoから抽出する必要があります.まずredoを行い、undoはredoによって保護されるので、redoからリカバリできます(テンポラリテーブルundoを除き、テンポラリテーブルundoはredoを記録しません).

クラッシュが回復すると、最後のBinlogファイルをスキャンし、xidを抽出します.

InnoDBは、Prepare状態のトランザクションチェーンテーブルを維持し、これらのトランザクションのxidとBinlogに記録されているxidを比較し、Binlogに存在する場合はコミットし、そうでない場合はトランザクションをロールバックします.

binlog  rotate     binlog    ，        binlog             sync redo    ，    ，   binlog                      .

  このようにして、InnoDBとBinlogのトランザクション状態を一致させることができます.sync binlog後にクラッシュすると、リカバリ時にcommitフラグが再書き込みされます.sync binlogの前でクラッシュすると、ロールバックします.
クラッシュリカバリはbinlogのxidとredo logのxidを比較し,xidがbinlogに存在するとコミットし,存在しないとロールバックする.
三、binlogグループの提出
3.1なぜグループ提出が必要なのか
sync_binlog=1の場合、上述したcommitフェーズにおけるwrite/sync binlogがボトルネックとなり、グローバルロック(prepare_commit_mutex:prepareとcommitが1本のロックを共用)を持っていることが明らかになり、パフォーマンスが急激に低下する.解決策はMySQL 5です.6で導入したbinlogグループがコミットされます.
3.2組提出原理
Binlog Group Commitのプロセスは、次の3つのフェーズに分割されます.

flush stageは、各スレッドのbinlogをcacheからファイルに書き込む.

sync stageはbinlogに対してfsync操作を行う(必要であれば、最も重要なのはこのステップで、複数のスレッドのbinlogに対してディスクに書き込む).

commit stageは、各スレッドのエンジンレイヤのトランザクションcommitを行います(ここではredo logは書かず、prepareフェーズで書かれています).各ステージには同時に1つのスレッドしか動作しません.(3つのフェーズに分けられ、各フェーズのタスクは専門的なスレッドに割り当てられ、同時に最適化されます).この実装の利点は、3つの段階が同時に実行され、効率が向上することである.