なぜマスター/スレーブレプリケーションを行うのでしょうか?

MySQL のマスター/スレーブの遅延を経験した後、マスター/スレーブのレプリケーションとは何だろうと考え始めました。それはどのように達成されるのでしょうか?どのように機能するのでしょうか?そこで、情報や記事を調べ始め、今ここで理解した内容をまとめて感想を深めていきたいと思います。

なぜマスター/スレーブレプリケーションを行う必要があるのですか?

1. 複雑なビジネスを伴うシステムでは、SQL ステートメントでテーブルをロックする必要があるシナリオがあり、その結果、読み取りサービスが一時的に使用できなくなり、実行中のビジネスに大きな影響を及ぼします。メイン ライブラリが書き込みを担当し、スレーブ ライブラリが読み取りを担当します。これにより、メイン ライブラリがテーブルをロックした場合でも、スレーブ ライブラリからの読み取りによってビジネスの正常な動作が保証されます。

2. データのホットバックアップ

3. アーキテクチャの拡張。業務量はますます増大しており、I/O アクセス頻度が高すぎるため、1 台のマシンでは対応できなくなり、ディスク I/O アクセス頻度を低減するためにマルチデータベース ストレージが使用されます。単一マシンの I/O パフォーマンスを向上させます。

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

binlog: バイナリ ログ、メイン ライブラリ内のすべての更新イベント ログを保存するバイナリ ファイル。

マスター/スレーブ レプリケーションの基礎は、マスター データベースがデータベース内のすべての変更を binlog に記録することです。 Binlog は、データベース サーバーの起動時からデータベース構造またはコンテンツに対するすべての変更を保存するファイルです。

MySQL マスター/スレーブ レプリケーションは、マスター ライブラリがスレーブ ライブラリに更新イベントを送信し、スレーブ ライブラリが更新レコードを読み取り、更新レコードを実行してスレーブ ライブラリの内容をマスター ライブラリと一致させる非同期レプリケーション プロセスです。 。

メインライブラリでは、更新イベントが発生する限り、順次バイナリログに書き込まれ、スレーブライブラリからレプリケーション用のデータソースとしてスレーブライブラリにプッシュされます。

binlog 出力スレッド。 スレーブ ライブラリがメイン ライブラリに接続するたびに、メイン ライブラリはスレッドを作成し、バイナリ ログのコンテンツをスレーブ ライブラリに送信します。
スレーブ ライブラリに送信されようとしている SQL イベントごとに、binlog 出力スレッドがそれをロックします。イベントがスレッドによって読み取られると、ロックは解放されます。イベントがスレーブ ライブラリに完全に送信された場合でも、ロックは解放されます。

スレーブ ライブラリでは、コピーが開始されると、処理のために 2 つのスレッドを作成します:

スレーブ ライブラリ I/O スレッド。 START SLAVE ステートメントがスレーブ ライブラリから実行を開始すると、スレーブ ライブラリは I/O スレッドを作成します。このスレッドはメイン ライブラリに接続し、binlog 内の更新レコードをスレーブ ライブラリに送信するようにメイン ライブラリに要求します。
スレーブ ライブラリの I/O スレッドは、メイン ライブラリの binlog 出力スレッドによって送信された更新を読み取り、これらの更新をリレー ログ ファイルを含むローカル ファイルにコピーします。

データベースからの SQL スレッド。 ライブラリから SQL スレッドを作成します。このスレッドは、ライブラリの I/O スレッドによってリレー ログに書き込まれた更新イベントを読み取り、実行します。

各マスター/スレーブ レプリケーション接続には 3 つのスレッドがあることがわかります。複数のスレーブ ライブラリを持つメイン ライブラリは、メイン ライブラリに接続されている各スレーブ ライブラリに対して binlog 出力スレッドを作成します。各スレーブ ライブラリには独自の I/O スレッドと SQL スレッドがあります。

スレーブライブラリは、2つの独立したスレッドを作成することで、コピー時のスレーブライブラリの読み取りと書き込みを分離します。したがって、実行を担当するスレッドの動作が遅くなったとしても、更新ステートメントの読み取りを担当するスレッドは遅くなりません。たとえば、スレーブ ライブラリがしばらく実行されていない場合、ここでスレーブ ライブラリを開始すると、SQL スレッドの実行は遅くなりますが、I/O スレッドはメイン ライブラリからすべての binlog コンテンツを迅速に読み取ることができます。このようにして、SQL スレッドがすべての読み取りステートメントの実行を完了する前にスレーブ ライブラリの実行が停止した場合でも、I/O スレッドは少なくともすべての内容を完全に読み取り、スレーブ ライブラリのローカル リレー ログにそれらを安全にバックアップします。 、次回スレーブ ライブラリが開始されたときにステートメントを実行する準備ができています。

マスター/スレーブ レプリケーションのステータスを確認する

マスター/スレーブ レプリケーションの進行中に、スレーブ ライブラリ内の 2 つのスレッドの実行ステータスを確認したい場合は、スレーブ ライブラリには次のフィールドが提供されます。 必要な情報:

Master_Log_File — 上一个从主库拷贝过来的binlog文件
Read_Master_Log_Pos — 主库的binlog文件被拷贝到从库的relay log中的位置
Relay_Master_Log_File — SQL线程当前处理中的relay log文件
Exec_Master_Log_Pos — 当前binlog文件正在被执行的语句的位置

マスター/スレーブ レプリケーション プロセス全体は、次の図で理解できます:

• ステップ 1: 更新イベント (更新、挿入) 、削除) は、メイン データベース db の binlog に書き込まれます

• ステップ 2: スレーブ ライブラリから接続を開始し、メイン ライブラリに接続します

• ステップ 3: この時点で、メイン ライブラリは binlog を作成しますスレッドをダンプし、ビンログの内容をスレーブ ライブラリに送信します

• ステップ 4: スレーブ ライブラリから開始します。その後、I/O スレッドを作成し、メイン ライブラリからバイナログの内容を読み取り、リレー ログに書き込みます

• ステップ 5: Exec_Master_Log_Pos 位置から開始して、リレー ログからコンテンツを読み取る SQL スレッドも作成されます。 読み取り更新イベントを実行し、更新されたコンテンツをスレーブの db に書き込みます

注：上面的解释是解释每一步做了什么，整个mysql主从复制是异步的，不是按照上面的步骤执行的。

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