この記事では、MySQLのマスタースレーブ同期の原理を説明します。

MySQL マスタースレーブ同期原理の簡単な分析

原理の説明を始める前に、まずは知識をまとめてみましょう。
マスタースレーブとは何か、なぜマスタースレーブが必要なのか、マスタースレーブをどのように実装するのか、MySQL マスタースレーブ同期の原理

1. マスタースレーブとは何ですか?

実際、マスター スレーブの概念は非常に単純です。ホストは、読み取りと書き込みに通常使用するサービスです。これをマスターと呼びます。
スレーブはホストの拡張機能です。通常は読み取りや書き込みには使用されません。これをスレーブと呼びます。
スレーブ上のデータは、何らかの形でホストから取得され、スレーブに書き込まれます。理論的には、スレーブは外部から直接データを取得することはできません。

2. 主従関係はなぜ必要なのでしょうか?

最も初期のマスター スレーブ システムはマスター スレーブ、つまりマスターがメイン マシンでスレーブがバックアップ マシンでした。初期のソフトウェアではデータ量と同時実行性が高くなかったためです。ホストは日常的な使用を完全にサポートできます。
したがって、マスタースレーブモードを通じてデータベースの高可用性が保証されます。マスターデータベースのダウンが検出されると、サービスのデータソースは自動的にバックアップデータベースに切り替わります。
ビジネスが発展するにつれて、単一のマスターではビジネスニーズをサポートできないことがわかったので、従来のマスター/スレーブ システムを拡張し始めました。

（１）マスター１台とスレーブ１台。スレーブはバックアップマシンとしてだけでなく、データソースを読み取るためのデータベースとしても機能します。業務サービスがデータを書き込むときはマスターマシンに書き込み、データを読み取るときはスレーブマシンから読み取ります。これにより、ホストへの負荷が軽減されます（2）1つのマスターと複数のスレーブ。マスターが書き込み、スレーブが読み取りを行った後、ビジネスクエリデータをサポートするときに単一のスレーブノードでは依然としてパフォーマンスのボトルネックがあることがわかったため、スレーブを水平に拡張して複数のスレーブを実現します。
（３）ダブルM
スレーブはマスターに昇格し、2つのマスターは互いにスレーブとなり、読み取りと書き込みの負荷を共有します。 (4) カスケードレプリケーション カスケードレプリケーションは、1つのマスターと複数のスレーブに似ていますが、セカンダリスレーブのデータソースがマスターではなくスレーブから取得される点が異なります。これは主に、スレーブの数が増えた後に同期データがホストのパフォーマンスに与える影響によるものです。（5）複数のマスターと1つのスレーブ。書き込みが多く読み取りが少ないシナリオでは、複数のマスターを使用してホストへの負荷を軽減し、1つのスレーブを使用して読み取り操作とデータバックアップを完了します。

3. マスタースレーブ同期を実現するにはどうすればいいですか?

マスター スレーブ同期は理解するのが難しすぎると考えないでください。実際には非常に簡単です。ソフトウェア エンジニアにとって必要なのは、コードを記述し、マスター データベースからデータを検索し、バックアップ データベースに接続して、そこにデータを書き込むことだけです。これは、最も理解しやすいマスター スレーブ同期です。
しかし、この方法はあまりにも大雑把でパフォーマンスも悪いため、MySQL 自体は、ホストからスレーブへのデータの効率的な同期を保証する完全なマスター スレーブ同期メカニズムを提供しています。
MySQL 独自のマスター スレーブ同期に加えて、業界には Alibaba の Canal など、それをサポートするコンポーネントもいくつかあります。これは主に、同期されたデータの解析など、より柔軟なデータ同期のためです。同期されたスレーブ マシンは、MySQL ではなく、他のストレージ サービスを使用する必要がなくなりました。

4. MySQLのマスタースレーブ同期の原理

MySQL 自体は、主に binlog ログを使用して、マスターとスレーブの同期を実装しています。
この記事の焦点では​​ないので、binlog ログについて簡単に説明します。
これは、MySQL が DB の変更を記録するために使用するログです。
たとえば、データの値が 0 から 1 に変更されます (DML ステートメント)
たとえば、テーブルが削除される（DDL文）
binlog には 3 つの形式があります。
（１）ステートメント：insert xxxxx...など、変更を引き起こした特定の操作ステートメントを記録します。
（2）行：データ行に基づきます。元のデータ行の値はxxからyyに変更されます。このタイプのデータ行は通常、より多くのスペースを占有します。
（３）混合：混合モードでは、サービス自体が変更の形式を決定します。
SQL 操作が binlog に書き込まれると、対応するディスク (フラッシュ ディスク) に書き込まれるのではなく、SQL 実行が成功したとみなされます。したがって、binlog 内の対応する値は、mysql のマッピングとして理解できます。mysql データの同期は、ディスク内のデータの同期とは異なりますが、必要なのは binlog ログの同期だけです。
具体的な同期の原則は次のとおりです。
（１）マスタースレーブ同期が設定された後（IP、ポート、サービスIDなどの関連操作が設定された後）
(2) 関連する変更がバイナリログに書き込まれます。 (3) マスターはスレッドを開始します: バイナリログ ダンプログ スレッド。 このスレッドは、SQL の変更があったことをスレーブに通知し、バイナリログの変更をスレーブに送信します。 (4) スレーブは要求を受信すると、スレッドを開始します: i/o スレッド。 このスレッドは、受信したバイナリログ ログをリレー ログ遅延ログにロードします。 (5) スレーブ内の別のスレッド: SQL スレッドがリレー ログの情報を読み取り、スレーブに更新します。 詳細については、下の図を参照してください。

CAP 理論 (ここでは明確ではありません) によれば、このアーキテクチャでは次のようなリアルタイムのデータ一貫性を保証することはできません。
1. ホストへの書き込み後、ホストはすぐにハングアップし、マスター/スレーブ切り替えが実行され、この時点でデータが失われる可能性があります。
2. マスターで書き込み操作が発生すると、スレーブのバイナリログへのデータの同期に遅延が発生します。そのため、スレーブにすぐにクエリを実行しても、データが見つからない場合があります。この状況の解決策は次のとおりです。
1. 半同期レプリケーションを有効にします。以前は、マスターとスレーブの同期情報は非同期であり、マスター データベースのロジックには影響しませんでした。半同期レプリケーションでは、ホストは、バイナリログが (少なくとも 1 つの) スレーブのリレー ログに書き込まれるのを待ってから、クライアントに返すことを決定します。
2. 機密データをホストに強制的に呼び出すが、これにより読み取りと書き込みの分離の概念が曖昧になるため、推奨されない。
3. ミドルウェア (チャネル) を使用します。一般的な原則としては、書き込み要求が発生すると、それがキャッシュに記録され、スレーブに同期する時間が推定されます。
マスター データベースにデータを書き込んでスレーブ データベースを照会する場合、キャッシュへの書き込みの推定時間を使用してスレーブ マシン上の時間が決定され、スレーブ データベースを待機するか、スレーブ データベースを直接照会するかが決定されます。

これで、MySQL マスター スレーブ同期原理の理解に関するこの記事は終了です。MySQL マスター スレーブ同期原理の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。