MySQL データベースは XA 仕様をどのように実装しますか?

MySQL 一貫性ログ

MySQL データベースの電源が切れた場合、コミットされていないトランザクションはどうなりますか?

回答: ログに頼ります。

操作を実行する前に、データベースはまず操作の内容をファイル システム ログに書き込み、その後操作を実行するためです。システムがクラッシュしたり、電源が落ちたりした場合、操作が完了していなくても、操作前にログが書き込まれているため、ログの内容に基づいて復旧することができます。

MySQL InnoDB エンジンでは、REDO ログ、ロールバック ログ、バイナリ ログが一貫性に関係します。

再実行ログ

操作が実行されるたびに、データが実際に変更される前に、関連する操作が REDO ログに書き込まれます。これにより、予期せぬ停電やその他の事故が発生し、後続のタスクを完了できなくなった場合でも、システムの復旧後にこれらの変更を続行できます。

元に戻すログ

REDO ログ (UNDO ログとも呼ばれます) に対応し、トランザクションが開始する前のデータの状態を記録します。

予期しない状況により一部の変更が完了できなかった場合、元に戻すログに基づいて変更前の状態を復元できます。

たとえば、トランザクション T1 はデータ X を更新し、X に対して更新操作を実行して、データを 10 から 20 に更新します。対応する Redo ログは <T1, X, 20> で、Undo ログは <T1, X, 10> です。

バイナリログ

MySQL サーバー層で保持されるバイナリ ログです。MySQL の最も重要なログの 1 つです。select や show などのデータ クエリ ステートメントに加えて、ステートメントの実行時間を含むすべての DDL および DML ステートメントが記録されます。

Binlog は、InnoDB エンジンの redo/undo ログとは異なります。主な目的はレプリケーションとリカバリです。MySQL データを更新する、または更新する可能性のある SQL ステートメントを記録し、トランザクション ログの形式でディスクに保存するために使用されます。

Binlog は主に MySQL のマスター スレーブ レプリケーション プロセスで使用されます。MySQL クラスターはマスター側で Binlog を開始します。マスターはバイナリ ログをスレーブ ノードに渡し、スレーブ ノードはそれを再生してマスター スレーブ間のデータ整合性を実現します。

次のコマンドを使用して、MySQL サーバーに接続し、実際の binlog データを表示できます。

// binlog ファイルの内容を表示します。show binlog events;

// 指定された binlog ファイルの内容を表示します。show binlog events in 'MySQL-bin.000001';

//書き込まれているバイナリログファイルを表示する show master status\G
 
// バイナリログファイルリストを取得します。バイナリログを表示します。

XA仕様の定義方法

XA は、X/Open 組織によって提案された分散トランザクション仕様です。XA 仕様は、主にトランザクション コーディネータ (トランザクション マネージャ) とリソース マネージャ (リソース マネージャ) 間のインターフェイスを定義します。

トランザクションマネージャー

XA トランザクションは 2 フェーズ コミット プロトコルに基づいているため、コーディネーターはすべてのトランザクション参加者が 2PC の最初のフェーズである準備作業を完了したことを確認する必要があります。

トランザクション コーディネーターは、すべての参加者が準備完了であるというメッセージを受信すると、すべてのトランザクションにコミット可能であることを通知します。これが 2PC の第 2 フェーズです。

トランザクション コーディネーターを導入する必要がある理由は、分散システムでは、2 台のマシンが理論上一貫した状態に到達できず、調整のために単一のポイントを導入する必要があるためです。

リソース マネージャー

データベースや JMS キューなどの実際のリソースの制御と管理を担当します。

現在、主流のデータベースはすべて XA をサポートしています。JMS 仕様、つまり Java Message Service では、XA に基づくトランザクションのサポートも定義されています。

XAトランザクション実行プロセス

XA トランザクションは、2 フェーズ コミットの実装です。2PC 仕様によれば、XA はトランザクションを準備とコミットの 2 つのフェーズに分割します。

準備段階

TM はすべての RM に準備指示を送信します。指示を受け取った RM は、データの変更やログ記録などの操作を実行し、タスクを送信できるかどうかを示すメッセージを TM に返します。

トランザクション コーディネーター TM は、すべての参加者が準備完了したというメッセージを受信すると、すべてのトランザクションにコミットするように通知し、第 2 フェーズに入ります。

コミットフェーズ

TM はすべての RM から準備結果を受信します。RM が結果を送信できないかタイムアウトしたと返した場合、TM はすべての RM にロールバック コマンドを送信します。

すべての RM がトランザクションを送信できると返した場合、トランザクション操作を完了するためにすべての RM にコミット コマンドが送信されます。

MySQL が XA 仕様を実装する方法

MySQL には、内部 XA と外部 XA の 2 種類の XA トランザクションがあります。違いは、トランザクションが単一の MySQL サーバー上で発生するか、複数の外部ノード間で発生するかです。

内部 XA

MySQL の InnoDB ストレージ エンジンでは、binlog が有効になっている場合、MySQL は binlog ログと InnoDB の redo ログの両方を維持します。2 つのログの一貫性を確保するために、MySQL は XA トランザクションを使用します。これは単一の MySQL マシンで動作するため、内部 XA と呼ばれます。

内部 XA トランザクションは、バイナリ ログのコーディネーターです。トランザクションがコミットされると、コミット情報がバイナリ ログに書き込まれる必要があります。つまり、バイナリ ログの参加者は MySQL 自身です。

外部XA

外部 XA は典型的な分散トランザクションです。MySQL は XA START/END/PREPARE/Commit などの SQL ステートメントをサポートしています。これらのコマンドを使用することで分散トランザクションを完了できます。

その他の XA コマンドについては、MySQL の公式ドキュメントも参照してください。

MySQL 外部 XA は主にデータベース プロキシ層で使用され、Taobao の TDDL、Alibaba B2B の Cobar などのオープン ソース データベース中間層などの MySQL データベースの分散トランザクション サポートを実装します。

外部 XA は一般に、複数の MySQL インスタンスにわたる分散トランザクションに使用され、アプリケーション層がコーディネーターとして機能する必要があります。たとえば、ビジネス コードを記述する場合、コード内でコミットするかロールバックするかを決定し、クラッシュが発生した場合に回復します。

binlog 内の Xid

トランザクションがコミットされると、バイナリログが依存する内部 XA に追加の Xid 構造が追加されます。バイナリログには複数のデータ型があります。

1. ステートメント形式、レコードはコミットを含む基本ステートメントです
2. 行形式、レコードは行に基づいています
3. 混合形式、ログレコードは混合形式を使用します

ステートメントや行の形式に関係なく、binlog はトランザクションの終了時に XID_EVENT を追加します。このイベントはトランザクション ID、つまり Xid を記録します。MySQL がクラッシュ リカバリを実行する場合、binlog 内のコミットのステータスに基づいてリカバリ方法を決定します。

Binlog同期プロセス

binlog でのトランザクション送信プロセスを見てみましょう。全体的なプロセスは、最初に redo ログを書き込み、次に binlog を書き込むというもので、binlog の書き込みが成功すれば、トランザクション送信が成功したことの印として使用されます。

トランザクションがコミットされると、次のようになります。

• InnoDB は準備フェーズに入り、REDO ログの書き込み/同期、REDO ログの書き込み、トランザクション xid の REDO ログへの書き込みを行いますが、バイナリログに対しては何も操作を実行しません。
• binlog の書き込み/同期、binlog ログの書き込み、および xid の binlog への書き込み
• InnoDBエンジンのコミットを呼び出してトランザクションを完了し、コミット情報をREDOログに書き込みます。

最初のステップと 2 番目のステップが失敗した場合、トランザクション全体がロールバックされます。

3 番目のステップが失敗した場合、MySQL は再起動後に xid がコミットされたかどうかを確認します。コミットされていない場合、つまりトランザクションを再実行する必要がある場合は、ストレージ エンジンで別のコミット操作を実行して、REDO ログと binlog データの一貫性を確保し、データ損失を防ぎます。

実際の実行には、オペレーティング システムのキャッシュ バッファーがファイル システムに同期されるタイミングも含まれるため、MySQL では、コミット時にログ バッファー内のログをログ ファイルにフラッシュする方法をユーザーがカスタマイズできるようにサポートされています。これは、変数 innodb_flush_log_at_trx_Commit の値によって決まります。

ログ バッファの内容はダーティ ログと呼ばれます。興味のある方は、詳細情報を確認してください。

上記は、MySQL データベースが XA 仕様を実装する方法の詳細です。MySQL データベース XA 仕様の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。