MySQL のマスター/スレーブ レプリケーションの原理は何ですか

はじめに

実際の本番環境では、セキュリティ、高可用性、または高同時実行性の点に関係なく、MySQL データベースの読み取りと書き込みがすべてデータベース サーバー上で実行される場合、実際のニーズを満たせない場合は、通常、 マスター/スレーブ レプリケーションを通じてデータを同期し、読み取りと書き込みの分離を通じてデータベースの同時負荷容量を向上させる必要があります。

1. マスター/スレーブ レプリケーションの概念

マスター/スレーブ レプリケーションは、MySQL が提供する基本テクノロジーです。マスター/スレーブ レプリケーションのプロセス: binlog バイナリ ログ (クエリ、その他の変更を除く)関連する操作は binlog)、リレー ログ、および 3 つのスレッド (マスターの 1 つのスレッドとスレーブの 2 つのスレッド) に記録されます。

メイン ライブラリ (マスター) は、外部

データの追加、削除、変更、クエリ サービスを提供します。メイン ライブラリのデータに関係する変更は、binlog に書き込まれます。 スレーブ ライブラリ (スレーブ) は、 データ同期とデータ バックアップ に使用される専用スレッドを使用して、メイン ライブラリとデータ、権限、およびテーブル構造に関連する変更をメイン ライブラリのバイナリからスレーブ ライブラリに同期します。これは同等です。メイン ライブラリに加えられたすべての変更が渡されます。マスター/スレーブ レプリケーション メカニズムはスレーブ データベースに組み込まれています。

マスター/スレーブ レプリケーションの利点:

データ バックアップ、つまり、MySQL ミドルウェア mycat、 を使用してホット バックアップを作成することもできます。災害 、災害復旧も 高可用性 を反映して容量を達成できます。 災害復旧:
メイン ライブラリがハングアップした場合、ミドルウェア エージェント mycat はサービス リクエストをスレーブ ライブラリに自動的にマッピングし、スレーブ ライブラリは高可用性を反映して外部にサービスを提供し続けます。 -エンド サービス 特定の例外の発生は許可されていますが、バックエンド アーキテクチャ サービスはフォールト トレラントであり、これらの異常なエラーを処理し、外部に通常のサービスを再提供する必要があります) 2. の概念読み取りと書き込みの分離

読み取りと書き込みの分離は、マスター/スレーブ レプリケーションに基づいて実装されます。実際のアプリケーション環境では、多くの読み取り操作が必要になるため、電子商取引プラットフォームで何かを購入するときと同じように、100 個の商品を見て 1 つまたは 2 つしか購入しない可能性があります。したがって、書き込み更新操作よりも読み取り操作の方が常に多くなります。したがって、マスター/スレーブ レプリケーションに基づく読み取り/書き込み分離構成は、マスター データベースがデータの変更専用であることを意味します。書き込みの際、データはマスター データベースに排他的に書き込まれます。マスター データベースは、データの変更をマスター/スレーブを通じてスレーブに同期します。 binlog. ライブラリを介してレプリケーションを行うと、他のクライアント クエリ要求は最終的にスレーブ ライブラリにマップされ、1 つのメイン ライブラリと 2 つまたは 3 つのスレーブ ライブラリがあります。

メイン ライブラリは、データ更新 (書き込み操作) に特に使用されます。ライブラリは読み取り操作に特化して使用されます。これにより、読み取りと書き込みの負荷が適切に分散されます。メイン ライブラリに集中する必要はありません。バックエンドの同時処理能力が大幅に向上します。さらに、高可用性機能を備えており、災害発生時にメイン データベースに障害が発生した場合、指定されたスレーブ データベースをメイン データベースに切り替えることができます。

上の図のバイナリログは、マスター/スレーブレプリケーションがない場合でもバイナリログに書き込まれますが、マスター/スレーブレプリケーションは次のように実装されています。ビンログ。

3. メイン ライブラリとスレーブ ライブラリ

1. メイン ライブラリ

メイン ライブラリのマスター サーバーは

binlog ダンプ スレッド

を作成します。バイナリ ログの内容はスレーブ サーバー2 に送信されます。スレーブ ライブラリ

には専用の

I/O スレッド
• があります。 reading メイン ライブラリから送信されたコンテンツを受信するには、メイン ライブラリから送信された binlog コンテンツを受信し、それを

  リレー ログ に書き込みます。リレー ログはバッファを作成することに相当します。次のイベント を送信する前に、スレーブの実行が完了するのを待つ必要はありません。メイン ライブラリのバイナリ コンテンツを読み取って直接実行する代わりに、直接実行の欠点は、メイン ライブラリに大量のバイナリ コンテンツが含まれる可能性があり、スレーブ ライブラリから受信したバイナリ コンテンツの実行が非常に遅くなる可能性があることです。その結果、スレーブ ライブラリからの更新が行われ、データとメイン データベースの間のギャップはますます大きくなります。データのレプリケーションに遅れが生じる可能性があります。

  スレーブ ライブラリは
SQL スレッド
• も開始します。これは、特に

  リレー ログから 対応する操作を読み取り、すべての SQL を実行します。それらすべて、したがって スレーブ ライブラリのコンテンツとマスター ライブラリのコンテンツの同期が実現されます

  4. マスター/スレーブ レプリケーション プロセス

#マスター/スレーブ レプリケーション プロセス:

2 つのログ (binlog バイナリ ログとリレー ログ ログ) と 3 つのスレッド (マスターの 1 つのスレッドとスレーブの 2 つのスレッド)。

メイン ライブラリの更新操作は

binlog バイナリ ログ

に書き込まれます (メイン ライブラリは binlog スイッチをオンにする必要があります)

• マスターサーバーは

  binlog ダンプ スレッド
を作成し、バイナリ ログの内容をスレーブ サーバーに送信します

• スレーブ マシンは START SLAVE コマンドを実行してスレーブ サーバー上に IO スレッド を作成します。スレーブ サーバーはマスターのバイナリ ログを受信し、それをマスターのバイナリ ログにコピーします。リレーログ (メモリ内、高速読み取りおよび書き込み)。まず、スレーブが作業スレッド (I/O スレッド) を開始します。I/O スレッドはアクティブにマスターに接続します。その後、メイン ライブラリが ダンプ スレッド を開きます。ダンプ スレッドは、 I/O スレッド、ダンプ スレッドがマスターに追いついた場合 (メイン ライブラリのダンプ スレッドはバイナリ ログの内容の送信を完了し、メイン ライブラリのバイナリ ログはまだ送信していない)より多くのコンテンツが生成される)、ダンプ スレッドはスリープし、ビンログが新しいイベントを生成するのを待ちます。スレーブの I/O スレッドによって受信されたイベントは、リレー ログ

• スレーブのリレー ログに書き込まれます。 SQL スレッドプロセス処理の最後のステップでは、SQL スレッドがリレーから開始されます。ログからイベントを読み取り、イベントを実行してスレーブのデータを更新し、マスターのデータと同期します。 SQL スレッドが I/O スレッドと一致している限り、リレー ログは通常 OS キャッシュに配置されるため、リレー ログのオーバーヘッドは非常に小さくなります

#5マスター/スレーブ レプリケーション効果の表示

Linux 上の Centos をメイン ライブラリとして使用し、win10 上の mysql サーバーをスレーブ ライブラリとして使用してデモンストレーションします。 #マスター/スレーブ レプリケーションは一方向の同期であり、マスターの変更はスレーブに同期されます。マスター/スレーブ レプリケーションを設定する場合、マスター データベースとスレーブ データベースの間でデータが異なる場合があります。構成が完了すると、マスター データベースに対するすべての変更がスレーブ データベースに同期されます。

マスターは mytest データベースを作成します:

スレーブをチェックし、mytest が同期されていることを確認します:

マスターはユーザー テーブルを作成し、スレーブもユーザー テーブルを同期しました:

Linux 側の MySQL (マスター) が mytest ライブラリを削除します

#この時点で、mytest ライブラリが削除されます。 、スレーブの mytest はもう存在しません

show processlist

マスターの現在の環境で作業中のスレッドを表示できます

#スレーブの現在の環境で動作しているスレッドを表示します

##

以上がMySQL のマスター/スレーブ レプリケーションの原理は何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。