BinlogはMySQLにおいて重要なログであり、主にMySQLのマスターデータベースとスレーブデータベース間のデータ同期とレプリケーションに使用されます。この機能により、Binlogは他の種類のデータベースとのデータ同期や、ビジネスプロセスのイベント駆動設計にも使用されます。調査と分析の結果、MySQL Binlogを使用したイベント駆動設計の実装は見た目ほど簡単ではないことがわかりました。そこで、この記事ではMySQLのBinlog、Redo Log、および内部データ更新プロセスについて解説します。これらの技術の背後にある原理を説明することで、ビジネスプロセスに発生する可能性のある問題とその回避方法を分析します。この記事がMySQLの原理を理解し、この人気のデータベース技術をよりスムーズに使用できるようになることを願っています。

まず、会員注文システムの設計についてご紹介します。注文システムは、メッセージキュー（MQ）に直接メッセージを送信し、非同期メッセージを使用して後続のビジネスプロセスを駆動することで、メッセージ駆動型設計を実現しています。大まかなビジネスプロセス図を以下に示します。

図1: メッセージを直接送信する注文イベント駆動型システム

図2: Binlogベースのイベント駆動型注文

前述の通り、Binlogベースの注文イベント駆動型設計には多くの利点がありますが、後に隠れた問題が潜んでいることが判明しました。実験の結果、注文処理に遅延が発生することが時々あることが判明しました。

通常の処理では、注文の決済イベントを受信後、注文処理サービスは注文ステータスを確認します。注文ステータスが既に決済済みの場合、処理プロセスが開始されます。しかし、処理遅延が発生している注文の場合、注文処理サービスは決済イベントを受信後、データベースにクエリを実行し、注文が決済済みステータスではないことを確認します。調査の結果、データの同時実行による上書きの問題は排除され、注文ステータスのクエリはマスターデータベースで実行されるため、マスターとスレーブ間の同期遅延の問題は発生しません。

ビジネス システムが Binlog から生成された注文支払いイベントを受信し、その後メイン データベースを照会して注文データが未払い状態であることを確認する原因は何でしょうか?

この問題の原因については今は脇に置いて、まずデータを更新する際の MySQL の内部動作を見てみましょう。

>>>> 2段階の提出

• Redoログにコミットフラグが付いている場合、Redoログは実際に正常にコミットされたことを意味します。この場合は、トランザクションを直接コミットしてください。
• REDOログにコミットフラグが設定されていない場合、XID（トランザクションID）を使用して対応するバイナリログが照会され、ログの整合性がチェックされます。バイナリログが完了している場合はトランザクションがコミットされ、完了していない場合はロールバックされます。

>>>> MySQLデータ更新プロセス

1. エグゼキュータはまず、エンジンからID=2の行を取得します。IDは主キーであり、エンジンはツリー検索を用いてこの行を直接見つけます。ID=2の行を含むデータページが既にメモリ内に存在する場合は、エグゼキュータに直接返されます。そうでない場合は、まずディスクからメモリに読み込んでから返します。
2. エグゼキュータはエンジンから行データを受け取り、その値に1を加算して（例えば、元の値がNであればN+1）、新しい行データを取得します。そして、エンジンインターフェースを呼び出して、この新しい行データを書き込みます。
3. エンジンは新しいデータをメモリに更新します。次に、メモリデータページへの更新内容をREDOログバッファに記録します（REDOログバッファについてはここでは詳しく説明しません。REDOログに対する操作はファイルに直接書き込まれるのではなく、まずメモリに記録され、その後特定の時間にディスクに書き込まれるという点だけを覚えておいてください）。これでデータ更新操作は完了です。
4. 次に、トランザクションのコミット操作が実行されます。トランザクションのコミット中、REDOログは「Prepared」とマークされます。通常、この時点でREDOログはバッファからディスクに書き込まれます（innodb_flush_log_at_trx_commitの値が1の場合、トランザクションがコミットされるたびにREDOログがディスクに書き込まれます）。その後、InnoDBは実行が完了し、トランザクションをコミットできることをエグゼキュータに通知します。
5. 実行プログラムはこの操作の Binlog を生成し、Binlog をディスクに書き込みます。
6. 実行プログラムはエンジンのコミット トランザクション インターフェイスを呼び出し、エンジンは書き込んだばかりの Redo ログをコミット ステータスに変更して更新を完了します。

この図は、更新ステートメントの実行中における MySQL エグゼキュータ、InnoDB、Binlog および Redo Log 間の相互作用を示しています (濃い緑色の背景は MySQL エグゼキュータによって処理される段階を表し、薄い緑色の背景は InnoDB によって処理される段階を表します)。

MySQLの原理に関する上記の説明から、Binlogへの書き込みはトランザクションのコミットフェーズで行われることがお分かりでしょう。しかし、MySQLではサーバー層とストレージエンジン層で異なるログ構造が導入されているため、2フェーズコミットが採用されています。Binlogへの書き込みは、ストレージエンジンが実際にトランザクションをコミットする前に行われます。つまり、Binlogを介してデータを同期するシステム（MySQLスレーブ、他のデータベース、または業務システム）では、理論的には、MySQLマスターよりも早く最新のコミットデータが反映される可能性があります。

したがって、上記の注文処理サービスが Binlog に基づいて注文支払いイベントを受信した後に、対応する注文が支払われていないことを検出した理由は、注文処理サービスがデータを照会していたときに、注文支払いデータの更新操作が MySQL 内でまだ完全にコミットされていなかったためであると考えられます。

この現象は、検証プログラムを開発することで再現できました。検証プログラムは、トランザクションがコミットされた後に完全なBinlogを受け取ると、MySQLマスターデータベース上の対応するレコードを再度クエリし、その結果からトランザクションがコミットされる前のデータの概要を取得します。

さらに、一部のピアからは、スレーブ データベースがマスター データベースよりも早くデータの送信を認識するという問題に遭遇したという報告もあります。

問題の根本原因を理解した後、どのように解決するかを検討する必要があります。現在、この問題を解決するには、再試行とBinlogデータを直接使用するという2つの方法があります。

再試行はシンプルで分かりやすいアプローチです。問題はトランザクションの前にバイナリログがコミットされていることに起因しているため、後でクエリを再試行すれば自然に問題は解決します。しかし実際には、再試行の実装方法、そして過度または無限の再試行がサービス停止につながるかどうかを検討する必要があります。再試行を実装するには、スレッドスリープやメッセージ再送信などの方法を使用できます。スレッドスリープは、スレッドの使用率を低下させ、サービスが応答しなくなる可能性もあるため、一般的には推奨されません。しかし、この問題が発生する可能性が低いことを考慮すると、スレッドスリープは使用可能であると考えています。この方法はシンプルで実装が容易であるため、迅速な問題解決に適しています。

2つ目の再試行方法は、メッセージの再送信です。例えば、RocketMQでは、Consumerが `ConsumeConcurrentlyStatus.RECONSUME_LATER` を返すことで、メッセージの再送信をトリガーできます。ただし、この再試行方法は1つ目の方法よりもコストが高く、再試行間隔も比較的長くなるため、時間的制約が厳しいビジネスでは大きな影響を及ぼします。したがって、この方法を採用するかどうかは、ビジネスと技術の両方の観点から検討する必要があります。

再試行方法の検討に加えて、状態遷移がA→B→Aという順序で進むABA問題も考慮する必要があります。業務システムは状態Bを期待していますが、実際には状態Bに到達できない可能性があります。したがって、再試行を使用してこの問題を解決する前に、業務システムがABA問題を抱えている可能性を排除する必要があります。状態ABA問題はステートマシンなどを用いて解決できますが、ここではこれ以上説明しません。

リトライ以外にも、Binlogを直接利用するというアプローチがあります。Binlog（行形式）はデータの変更を直接反映し、トランザクションコミットに関わるすべてのデータを記録するため、業務処理に直接活用できます。これにより、データベースのQPSも削減できます。新規に設計するシステムには、このアプローチが理想的です。しかし、既存のシステムでは大幅な変更が必要になる可能性があり、導入の是非はコストとメリットを比較検討する必要があります。