簡単な説明：マスタースレーブレプリケーションは、スレーブデータベースと呼ばれるマスターデータベースとまったく同じデータベース環境を確立するために使用されます。マスターデータベースは通常、準リアルタイムのビジネスデータベーストランザクション処理データベースであり、スレーブデータベースが使用されます。クエリデータベースとして
1.マスター/スレーブレプリケーションとは
マスタースレーブレプリケーションは、スレーブデータベースと呼ばれるマスターデータベースとまったく同じデータベース環境を確立するために使用されます。マスターデータベースは通常、準リアルタイムのビジネスデータベースです。最も一般的に使用されるmysqlデータベースの中で、一方向および非同期レプリケーションがサポートされています。レプリケーションプロセス中、一方のサーバーはマスターサーバーとして機能し、もう一方のサーバーはスレーブサーバーとして機能します。このとき、マスターサーバーは更新情報を特定のバイナリファイルに書き込みます。
また、ログサイクルを追跡するためにファイルのインデックスを維持します。このログを記録して、サーバーから更新に送信できます。スレーブサーバーがマスターサーバーに接続すると、スレーブサーバーはマスターサーバーに通知して、サーバーのログファイルから最後に成功した更新の場所を読み取ります。次に、スレーブサーバーは、それ以降に発生した更新を受信し、ロックして、マスターサーバーが新しい更新を通知するまで待機します。
第二に、マスタースレーブレプリケーションの役割
1つは、データのセキュリティを確保することです。メインデータベースサーバーに障害が発生した後、バックアップデータベースとしてデータのホットバックアップを実行し、スレーブデータベースに切り替えて、データの損失を回避するための作業を続行できます。
2つ目は、I / Oパフォーマンスの向上です。日々の生産における取引量の増加に伴い、I / Oアクセスの頻度がますます高くなり、1台のマシンでは対応できません。現時点では、マルチデータベースストレージが使用されています。ディスクI / Oアクセスを効果的に削減する頻度は、単一デバイスのI / Oパフォーマンスを向上させます。
3つ目は、データベースがより大きな同時実行性をサポートできるように、読み取りと書き込みを分離することです。これは、レポートで特に重要です。一部のレポートのSQLステートメントが非常に遅いため、テーブルがロックされ、フロントデスクサービスが影響を受けます。フロントデスクがマスターを使用し、レポートがスレーブを使用する場合、レポートSQLによってフロントデスクがロックされることはなく、フロントデスクの速度が保証されます。
3つ目は、マスタースレーブレプリケーションの原則です。
マスタースレーブレプリケーションに関係するファイル
メインライブラリ：binlog
ライブラリから：
- リレーログリレーログ
- master.infoメインライブラリ情報ファイル
- Relaylog.infoリレーログアプリケーション情報
マスタースレーブレプリケーションに関係する3つのスレッド
メインライブラリ：
Binlog_Dumpスレッド：
ライブラリから：
SLAVE_IO_THREAD
SLAVE_SQL_THREAD
具体的な原理を図に示します。
- データベースからmastertoコマンドの変更を実行します（マスターデータベースの接続情報+レプリケーションの開始点）
- 上記の情報は、データベースからmaster.infoファイルに記録されます。
- データベースからstartslaveコマンドを実行して、SLAVE_IO_THREADとSLAVE_SQL_THREADの2つのスレッドをすぐに開始します。
- データベースSLAVE_SQL_THREADから、master.infoファイルの情報を読み取り、IP、PORT、User、Pass、binlogのロケーション情報を取得します。
- メインデータベースに接続するためのデータベースSLAVE_IO_THREAD要求から、メインデータベースは、リレーログを介したSLAVE_SQL_THREADとの対話を担当するSLAVE_IO_THREADを具体的に提供します。
- SLAVE_IO_THREADは、binlogのロケーション情報に基づいて、メインデータベースから新しいbinlogを要求します。
- マスターデータベースは、Binlog_DUMP_Threadを介して最新のbinlogを、ネットワークTPを介してスレーブデータベースのSALVE_IO_THREADに送信します。
- SLAVE_IO_THREADは、新しいbinlogログを受信し、それをTCP / IPキャッシュに格納し、すぐにACKをメインライブラリに返し、master.infoを更新します。
- SLAVE_IO_THREADは、TCP / IPキャッシュ内のデータをディスクリレーログにダンプします。
- SLAVE_SQL_THREADは、relay.infoの情報を読み取り、前回適用されたリレーログの位置情報を取得します。
- SLAVE_SQL_THREADは、最後の位置ポイントに従って最新のリレーログを再生し、relay.info情報を再度更新します。
- リレーは定期的なクリーニングのためにデータベースから自動的に削除されます
マスター/スレーブ接続ごとに3つのスレッドがあります。複数のスレーブを持つマスターは、現在接続されているスレーブごとにバイナリログダンプスレッドを作成し、各スレーブには独自のI / OスレッドとSQLスレッドがあります。
スレーブライブラリは2つのスレッドを使用して、読み取りと更新をメインライブラリから分離し、それらを独立したタスクに実行します。したがって、ステートメントの実行が遅い場合でも、ステートメントの読み取りタスクが遅くなることはありません。たとえば、スレーブサーバーが一定期間実行されていない場合、スレーブサーバーが起動すると、SQLスレッドが大幅に遅れていても、そのI / Oスレッドはマスターサーバーからすべてのバイナリログコンテンツをすばやく取得できます。 。SQLスレッドが取得したすべてのステートメントを実行する前にスレーブサーバーが停止した場合、I / Oスレッドは少なくともすべてを取得しているため、ステートメントの安全なコピーがスレーブリレーログにローカルに保存され、次回実行できるようになります。
マスタースレーブレプリケーションが正常に構築され、マスターデータベースで新しい変更が発生すると、slave_dump_THREADを介してSLAVE_IO_THREADにシグナルが送信され、マスタースレーブレプリケーションのリアルタイムパフォーマンスが向上します。
実際のプロジェクトでは、マスタースレーブレプリケーションは読み取りと書き込みの分離テクノロジーを組み合わせて、高いシステムパフォーマンスと高可用性を実現します。
マスタースレーブレプリケーションはデータベース構成によって実現されますが、読み取りと書き込みの分離は通常、プログラムによって制御されます。