MySQL レプリケーション メカニズムの原理の説明

背景

レプリケーションはデータの完全なコピーです。レプリケーションが必要な理由として、まず思い浮かぶのは、ユーザーに損失をもたらす可能性のある偶発的なデータ損失の恐れです。

データレプリケーションを完了すると、それ以上の利点があることがわかります。1 台のマシンがダウンしても、別のマシンにバックアップされたデータを有効にできます。結局のところ、ダウンタイムの確率は非常に小さく、バックアップマシンは空き時間にメインマシンのトラフィックの負荷を分担することができます。さらに、データベースのバージョンをアップグレードする必要がある場合は、ユーザー サービスを停止せずに最初にスタンバイ マシンをアップグレードし、メイン データベースが使用可能で安定していることが確認されたら、メイン データベースをアップグレードできます。

しかし、DBA が手動コピーでレプリケーションを完了できるとは限りません。DBA の勤務中にクラッシュが発生した場合、その期間に生成されたデータは時間内にバックアップされず、スタンバイ データベースでデータが失われることになります。そのため、自動レプリケーションのメカニズムを設計する必要があります。

複製メカニズムの設計

コピーしたデータベースをマスター データベース、貼り付けたデータベースをスレーブ データベースとして暫定的に定義します。マスター データベースからスレーブ データベースへのレプリケーションを実現するのは非常に簡単です。マスター データベースのデータ ファイルのコピーを定期的にコピーし、スレーブ データベースが配置されているサーバーに転送するスケジュールされたタスクのみが必要です。

しかし、結局のところ、スケジュールされたタスクはリアルタイムではありません。マスター データベースが最後のレプリケーションから 10 分後に失敗した場合、アクティブ化されたスレーブ データベースは最後にレプリケーションされたデータを使用するため、10 分間のデータが失われ、結果は悲惨なものになります。

リアルタイムのレプリケーションが依然として必要な場合は、マスター データベースは実行された各ステートメントをスレーブ データベースにリアルタイムで送信し、スレーブ データベースがそれを即座に実行できるようにすることで、両側のデータの一貫性を確保できます。

あまり良くないのは、マスター データベースがスレーブ データベースにデータをリアルタイムで送信し、スレーブ データベースの実行が終了してからでないと次のステートメントを処理できないため、マスター データベースの実行時間が大幅に消費されることです。スレーブ データベースが多すぎると、マスター データベースは役に立たなくなります。

メイン データベースの時間を節約するには、非同期に変更する必要があります。メイン データベースによって実行されたステートメントはファイルに保存され、スレーブ データベースはそれを取得できるため、メイン データベースはスレーブ データベースを待つ必要がありません。ファイルに書き込まれるため、速度が非常に高速です。メインデータベースは、実行前にステートメントをファイルに書き込むことで、より高い同期効率を実現できます。

上記の問題の一部では、スレーブ データベースはマスター データベースを実行してデータを取得することができません。スレッドを開始してマスター データベースとの接続を確立し、マスター データベースからデータを要求することしかできません。次に、マスター データベースもスレッドを開始してファイル コンテンツを読み取り、スレーブ データベース スレッドにプッシュします。ステートメントを受け取った後、スレーブ データベースはすぐにそれを実行できます。

これはまだ非常に非効率的です。マスター データベースのスレッドは、スレーブ データベースがステートメントを受信して​​実行を完了するまで待機してから、次のステートメントをプッシュする必要があります。スレーブ データベースが複数ある場合、マスター データベースは各スレーブ データベースとの長期通信を維持するために複数のスレッドを開始する必要があり、マスター データベース サーバーのリソースを占有します。スレーブ データベースでは、マスター データベースから送信されたステートメントを一時的に保存するファイルを作成し、最初に保存してからゆっくりと実行する方がよいでしょう。これにより、マスター データベースへの負荷が軽減され、スレーブ データベースも軽減されます。

スレーブにリレー用の独自のファイルが用意されたので、心配する必要はありません。スレーブは別のスレッドを開始し、リレー ファイル内のステートメントをゆっくりと実行できます。実行が完了すると、元のファイルには価値がなくなり、サーバー リソースの占有を避けるためにクリーンアップできます。

これまで、最も基本的なレプリケーション メカニズムが設計されています。マスター データベースからスレーブ データベースへのこのレプリケーション方法は、典型的なマスター スレーブ アーキテクチャであり、これに基づいて進化させることができます。たとえば、スレーブ データベースが多数ある場合、マスター データベースは各スレーブ データベースにデータをプッシュする必要があり、それに応じてマスター データベースへの負荷が増加します。マスター データベースの役割は、データの同期だけでなく、データの読み取りと書き込みも行うため、データ同期タスクは他の誰かに置き換えることができます。たとえば、マスター データベースとスレーブ データベースの間に別のマスター データベースが確立されます。新しく確立されたマスター データベースの役割は、スレーブ データベースにデータを同期することです。このようにして、実際のマスター データベースは、新しく確立されたマスター データベースにデータを 1 回プッシュするだけで済み、残りの時間はデータの読み取りと書き込みに集中できます。

この進化したレプリケーションモードは、マルチレベルレプリケーションアーキテクチャと呼ばれます。この記事はここで終わります。上記は、3つのレプリケーションアーキテクチャのうちの2つです。さらに、「マスターマスター」アーキテクチャもあります。ここでは詳細には触れません。興味がある場合は、自分で詳しく調べたり、以降の記事に注目したりしてください。

以上がMySQLレプリケーションメカニズムに関する知識のすべてです。123WORDPRESS.COMへのご支援に感謝いたします。