MySQL がマスター/スレーブ レプリケーション プロセスを実装する方法の詳細な例 (写真)

この記事では主に MySQL マスター/スレーブ レプリケーションの実装プロセスを詳しく紹介します。興味のある方は参考にしてください

1. マスター データベースを DDL に統合します。 DML 操作はバイナリ ログ (BINLOG) を通じてスレーブ データベースに送信され、これらのログが再実行 (やり直し) されて、スレーブ データベースのデータがマスター データベースと一致します。

2. マスター/スレーブレプリケーションの役割

1. マスターデータベースに問題が発生した場合、スレーブデータベースに切り替えることができます。

2. データベースレベルで読み取りと書き込みの分離を実行できます。

3. レプリケーションプロセス

のバイナリログ。マスターデータベース

リレーログ:サーバーからのリレーログ

ステップ1:

マスターは、各トランザクション更新データが完了する前に、操作レコードをbinlogファイルにシリアルに書き込みます。

ステップ 2:

salve は I/O スレッドを開きます。このスレッドはマスター上で通常の接続を開き、その主なジョブは binlog ダンプ プロセスです。読み取りの進行状況がマスターに追いついた場合、マスターはスリープ状態に入り、マスターが新しいイベントを生成するのを待ちます。 I/O スレッドの最終的な目的は、これらのイベントをリレー ログに書き込むことです。

ステップ 3:

SQL スレッドはリレー ログを読み取り、ログ内の SQL イベントを順番に実行して、メイン データベース内のデータとの一貫性を保ちます。

4. マスター/スレーブレプリケーションの具体的な操作

同じウィンドウ上の異なるパスに 2 つの msyql インスタンスをインストールしました。ここでは、マスターとスレーブ間でインストールされている mysql のバージョンが一貫していることをお勧めしますが、私のバージョンは一貫していません。

1. マスターデータベースとスレーブデータベースの設定ファイル my.ini をそれぞれ変更します

master

3306 は、mysql のデフォルトのポート番号を変更する必要はありません。ここで、server-id は、異なる mysql インスタンスで重複しないことを指定するために使用されます。binlog-do-db は、バイナリ ログを開くために使用されるデータベースを指定します。ファイル。

salve

マスターデータベースとスレーブデータベースは後で同じコンピューター上で実行されるため、ポートを異なるものに設定する必要があります。ここでは、3307

replicate-do-db: の名前を示します。マスター上の構成と一致するように同期する必要があるデータベース。

2. マスター上でレプリケーション専用のアカウントを作成します: weidai/123456

この新しく追加されたアカウントはテーブル mysql.user でクエリできます:

これが私の最初の操作です, ここでこのアカウントの作成は完了しましたが、実際にコピーしてみると、エラーのトラブルシューティングを行ったところ、マスターが生成したbinlongには問題がないことが分かりました。そして、スレーブのステータスを確認しました:

最後に次のようなエラーがあります:

Weidai アカウントを使用するとマスターに接続できないため、マスターのバイナリログを取得すべきではありませんそのため、リレー ログを生成できなくなります。

アカウントとパスワードを繰り返し確認しましたが、問題はありませんでした。その後、関連情報を検索したところ、マスターが新しいユーザーを作成するときに、次の手順が欠落していたためであることがわかりました。

新しいユーザーを設定した後、または変更した後。パスワードを指定するには、MySQL のシステム権限関連テーブルを更新するためにフラッシュ権限を使用する必要があります。そうしないと、アクセスが拒否されます。これが、前のエラーが発生した理由です。もう 1 つの方法は、mysql サーバーを再起動して新しい設定を有効にすることです。

3. 現時点でのメインデータベース内のデータの位置を取得します。ただし、このステータス値を取得する前に、データの開始位置をコピーするために使用されます。データを変更できなくなるため、最初に読み取りロックを有効に設定する必要があります

4. メイン ライブラリはデータのバックアップを実行します。バックアップの方法はここでは紹介しません。バックアップが完了したら、読み取りロックを解除して、メイン ライブラリを実行できます。書き込み操作

5 、スレーブ データベースを起動し、バックアップしたばかりのデータを復元します。この時点では、バックアップ時点のマスター データベースとスレーブ データベースのデータは一致しています。

6. データベースからのレプリケーション動作に関連する設定

7. この時点では設定は完了していますが、スレーブ データベースはまだ同期できないため、スレーブ スレッドを開始する必要があります

8. マスターでテーブルを作成し、新しく追加したデータをスレーブで観察します。

マスターで実行した操作がスレーブに反映されていることがわかります。このとき、スレーブは次のようになります。マスターの鏡。

5. マスターとスレーブの同期ステータスの解釈

スレーブでコマンドを使用して表示します:

レイアウトが見苦しいので、次のようにコンパイルしました:

Slave_IO_STATE:Waiting for master to send event
Master_host:127.0.0.1
Master_user:weidai
Master_port:3306
connnect_retry:60
Master_log_file:mysql-bin.000005
Read_Master_log_pos:1662
Relay_log_file:AE6Z*****-relay-bin.000002
Relay_log_pos:1415
Slave_IO_Running:yes
Slave_SQL_Running:yes

----- ----- -------------------------------------- ----- 華やかなセグメンテーションライン------------------------------------------ ------

Slave_IO_Running:yes

Slave_SQL_Running:yes

前述したように、これら 2 つのスレッドは、レプリケーション プロセスに参加するスレーブ上の 2 つの非常に重要なスレッドです。 YESは正常、NOは異常を意味します。

Slave_IO スレッドは主にマスターの binlong ログの内容をスレーブのリレー ログ (Relay_log) にコピーします。一般に、問題が発生する可能性はほとんどなく、アクセス許可またはネットワークの問題が原因で発生します。マスター。 。先ほどのエラーと同じです。

Slave_SQL スレッドはリレー ログ内の SQL を実行する責任があり、エラーの可能性が比較的高くなります。誰かがスレーブ データベースに手動でレコードを挿入すると、マスターとスレーブの同期中に主キーの競合が発生します。

Slave_IO_STATE: マスターがイベントを送信するのを待っています

このステータスは、リレーログの同期が完了し、マスターによって生成される新しいイベントを待っていることを示します。

以上がMySQL がマスター/スレーブ レプリケーション プロセスを実装する方法の詳細な例 (写真)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。