分散ストレージ - MySQL データベースのトランザクションとレプリケーション

「バックエンド分散」には、「分散ストレージ」と「分散コンピューティング」の 2 つのカテゴリが含まれます。実際の業務で遭遇する問題に対する答えを見つけるために、技術を分析します。多くの場合、私たちは新しいテクノロジーを生み出すのではなく、それを応用しています。テクノロジーをより効率的かつ効果的に使用するには、テクノロジーの原理と動作方法のいくつかを理解する必要があります。ユーザーの視点から技術原理を分析し、オープンソース技術製品とフレームワークをある種の技術のリファレンス実装として説明します。主な目的は原理を明確に説明することであり、具体的な実装の技術的な詳細については特に何もない場合は、簡潔に説明するようにしてください。

[[267623]]

トランザクションとレプリケーション

私は最近、MySQL データベースのデータ分散に関わるプロジェクトに参加しました。簡単に言えば、リモート データ センターでマルチポイント書き込みを実現し、分散データが最終的な一貫性を実現できるようにする必要があります。以前は、MySQL のデータ分散は単純に読み取りと書き込みの分離であり、データベース自体のマスター スレーブ レプリケーションを使用して、マスター データベースへの書き込みとスレーブ データベースからの読み取りを実現できました。ここで、メイン データベースを二重に書き込み、少し遅延した後に最終的な一貫性を実現する必要があります。この問題は一見複雑に思えますが、最終的には最終的なデータの一貫性の問題です。

最も単純なケースに戻りましょう。 MySQL データベースが 1 つしかない場合、データの一貫性はどのように保証されますか?データベースについて知っている人なら、これがデータベースのトランザクション特性によって保証されていることを知っています。トランザクションには 4 つの主要な特性があります。

• 原子性
• 一貫性
• 分離
• 耐久性

トランザクションの 4 つの ACID プロパティはこの記事の焦点では​​ないため、学術的な方法では詳しく説明しません。これらについてよく知らない場合は、以下の参考文献[3]の関連記事を読んでみてください。ここでちょっと質問したいのですが。単一のデータベース トランザクションでデータの一貫性を確保できます。では、MySQL をマスター/スレーブ アーキテクチャで導入する場合、マスターとスレーブ間のデータの一貫性をどのように確保できるでしょうか?

マスタースレーブレプリケーション機能を提供するために、MySQL では、データの変更をトリガーするイベントログのコレクションを含む binlog という新しいログファイルが導入されました。スレーブ データベースは、マスター データベースに binlog の送信を要求し、ログ イベントを通じてデータを復元してスレーブ データベースに書き込むため、スレーブ データベースのデータ ソースは binlog になります。このように、MySQL マスター データベースでは、マスター データベースとスレーブ データベースのデータの一貫性を確保するために、バイナリ ログをローカル データと一致させるだけで済みます (当面は、ネットワーク転送によって発生するマスターとスレーブ間の不整合は無視します)。ローカル データの一貫性を確保するには、データベースのトランザクション特性に依存することがわかっています。データベーストランザクションはどのように実装されますか?まず次の図を見てください。

MySQL 自体はトランザクション サポートを提供しませんが、特定のストレージ エンジンによって実装されるストレージ エンジン インターフェイスを開きます。具体的には、MySQL トランザクションをサポートするストレージ エンジンは InnoDB です。ストレージ エンジンがトランザクションを実装する一般的な方法は、REDO ログと UNDO ログに基づいています。簡単に言えば、REDO ログはトランザクションによって変更されたデータを記録し、UNDO ログはトランザクション前の元のデータを記録します。したがって、トランザクションが実行されると、実際に何が起こるかは次のように簡略化されます。

まず、元に戻す/やり直しログを記録して、ログが永続的なストレージのためにディスクにフラッシュされていることを確認します。

データ レコードを更新し、操作をキャッシュし、ディスクに非同期的にフラッシュします。

トランザクションをコミットし、コミット レコードを REDO ログに書き込みます。

MySQL トランザクションが障害により中断された場合、トランザクションは REDO ログを通じてやり直されるか、UNDO ログを通じてロールバックされ、データの一貫性が確保されます。これらはすべてトランザクション ストレージ エンジンによって実行されますが、binlog はトランザクション ストレージ エンジンの範囲内ではなく、MySQL サーバーによって記録されます。次に、binlog データと redo ログ間の一貫性を保証する必要があるため、binlog が有効になった後、実際のトランザクション実行には次の 1 つのステップが追加されます。

まず、元に戻す/やり直しログを記録して、ログが永続的なストレージのためにディスクにフラッシュされていることを確認します。

データ レコードを更新し、操作をキャッシュし、ディスクに非同期的にフラッシュします。

トランザクション ログを binlog に保存します。

トランザクションをコミットし、コミット レコードを REDO ログに書き込みます。

この場合、バイナリログが正常に書き込まれない限り、トランザクション全体をロールバックする必要があります。バイナリログが正常に書き込まれると、MySQL がクラッシュしてもトランザクションを復元してコミットできます。これを実現するには、binlog をトランザクションに関連付ける必要があります。バイナリログとトランザクション データの一貫性を確保することによってのみ、マスター スレーブ データの一貫性を保証できます。そのため、バイナリログ書き込みプロセスは、純粋なトランザクションストレージエンジン実行プロセスに埋め込まれ、2 フェーズコミットは内部分散トランザクション (xa トランザクション) の形式で完了する必要があります。詳細はここでは述べませんので、下記の参考文献[5]を参照してください。

要約する

まずは疑問点を提起し、MySQLの実装方法を参考にしながら、データの一貫性という観点から考えてみました。 MySQL スタンドアロン環境がレプリケーション メカニズムのデータ一貫性、つまり binlog とトランザクション データの一貫性をどのように確保するかを明確化し、分析します。その後、binlog メカニズムに基づいてレプリケーションを実装し、マスター スレーブ レプリケーションの一貫性を確保できます。マスター スレーブ レプリケーションではネットワーク要素が導入され、マスター スレーブ データの一貫性を確保する複雑さがさらに増します。この問題については、後の記事でさらに分析します。